Google Meet iOS app

[Sheridan]

Has anyone managed to get the iOS Google Meet app to work reliably, specifically through a smoothwall?

 

I've followed their setup and tcp/udp 19302-19309 is allowed, as well as https to the 74.125.250.0/24 and 142.250.82.0/24 ranges but it usually times out.

 

Normal browser based meet opens fine, but just the iOS app fails to connect. The smoothwall logs show nothing although I find that's the case a lot of times as it too slow to update

[DGardiner]

Has anyone managed to get the iOS Google Meet app to work reliably, specifically through a smoothwall?

 

I've followed their setup and tcp/udp 19302-19309 is allowed, as well as https to the 74.125.250.0/24 and 142.250.82.0/24 ranges but it usually times out.

 

Normal browser based meet opens fine, but just the iOS app fails to connect. The smoothwall logs show nothing although I find that's the case a lot of times as it too slow to update

Run the live weblock for your devices IP and see what its talking to its most likely the app using cert pinning somehwere along the line and then refusing to connect - the only thing i have open is the google ip block for this range https://support.google.com/a/answer/1279090?hl=en#zippy=%2Cstep-allow-access-to-uniform-resource-identifiers-uris%2Cstep-set-up-outbound-ports-for-media-traffic%2Cusing-proxies%2Cstep-allow-access-to-google-ip-address-ranges

 

and then sat and selectively added some google urls to whitelist/no inspect, likely related to the login - connect for chromebooks might cover this

[Sheridan]

It hits quite a range of IPs:

108.177.0.0/1617.173.255.0/24172.173.255.0/24172.217.0.0/16216.58.0.0/1674.125.250.0/24172.217.169.0/2474.125.250.0/24172.217.16.0/24142.250.0.0/16

 

Problem is, whitelisting them is whitelisting *.google.com which means if your smoothwall is the default gateway and the proxy is switch off on the device, then they have unfiltered access to google search!

[DGardiner]

It hits quite a range of IPs:

108.177.0.0/1617.173.255.0/24172.173.255.0/24172.217.0.0/16216.58.0.0/1674.125.250.0/24172.217.169.0/2474.125.250.0/24172.217.16.0/24142.250.0.0/16

 

Problem is, whitelisting them is whitelisting *.google.com which means if your smoothwall is the default gateway and the proxy is switch off on the device, then they have unfiltered access to google search!

 

The KB says its used exlusivelye for meet media?

 

[h=4]Google Workspace IP address ranges[/h]These IP ranges are used exclusively for Meet to identify video meeting traffic used with your organization’s Google Workspace accounts and to deprioritize Meet traffic from consumer accounts.

Allow access to Meet's media servers using the following set of IP ranges:

 

• IPv4: 74.125.250.0/24
  
• IPv6: 2001:4860:4864:5::0/64
  

[h=4]Consumer IP address ranges[/h]The following IP ranges are used exclusively for media traffic coming from participants who are signed in to a personal Google Account or not signed in to any account.

Allow access to Meet's media servers using the following set of IP ranges:

 

• IPv4: 142.250.82.0/24
  
• IPv6: 2001:4860:4864:6::/64
  

[DGardiner]

If you run the live logs while trying the app.

 

Avoid the root domain, but you can probably safely get away with the likes of accounts.google.com/co.uk etc apis.google.com etc justs needs a quick game of cat and mouse - this is an issue with pretty much and IOS app these days

[Sheridan]

Yeah I only had the original two IP ranges allowed, which didn't work, so I traced what was being blocked and it was the ranges above (usually https)

 

Unblocking those is not an option, as it gives access to unfiltered google search - and it allows access to very unsuitable content through the google images search!

 

The google document doesn't seem to differentiate between normal meet browser access and ios app access - I haven't tried it on android. Our ipads use a proxy which works for everything except Meet - which seems to ignore it and therefore wants a ton of addresses open on the firewall.

Edited June 1, 2021 by Sheridan

[DGardiner]

Yeah I only had the original two IP ranges allowed, which didn't work, so I traced what was being blocked and it was the ranges above (usually https)

 

Unblocking those is not an option, as it gives access to unfiltered google search - and it allows access to very unsuitable content through the google images search!

 

Youve missed something then.

 

Ive got the 2 ip ranged listed on the kb article and a few something.google.com urls set to not inspect and my phone works fine.

 

Quick check and nearly every url fell inside the Chromebook Connect category or the API and Web Libraries, just put a rule at the top of your ssl inspections for Websearch that is set to always inspect then underneath that apis/chromebook connect for dont inspect

 

These seem to be the ones making noise from my phone - though if you havent made it past login its likely one of the accounts. urls

 

https://hangouts.googleapis.com/

https://lh3.googleusercontent.com/

https://meetings.googleapis.com/

 

https://oauthaccountmanager.googleapis.com/

 

also depending on your authentication they may need excluded from that

Edited June 1, 2021 by DGardiner

[Sheridan]

Hmm, what I have setup is a rule to bypass https inspection for the google urls - including the ones you mention as well as the accounts. I also have a firewall rule to allow the https/19302-19309 ports out to the two google IP ranges as well

 

So the ipad has a smoothwall proxy/port set and therefore should use that - but it seems to hit the firewall on the a lot of the ranges I listed above, suggesting its ignoring the proxy setting altogether.

 

A snippet from the firewall log shows that its trying to access https for ranges out of the 2 google specify - and its blocked by the default rule (correctly!)

 

Edited June 1, 2021 by Sheridan

[DGardiner]

Hmm, what I have setup is a rule to bypass https inspection for the google urls - including the ones you mention as well as the accounts. I also have a firewall rule to allow the https/19302-19309 ports out to the two google IP ranges as well

 

So the ipad has a smoothwall proxy/port set and therefore should use that - but it seems to hit the firewall on the a lot of the ranges I listed above, suggesting its ignoring the proxy setting altogether.

 

Has this ipad logged in to its google account already or is this all pre login?

 

Im running transparent, no auth for mine. i dont have those ports open specifically, i just set any to the meet media servers - probably should close that down but since google said theyre used exclusively for meet i was fine with it.

 

Ive just tried an explicit proxy and its still working, though i have no auth enabled on it.

[Sheridan]

Has this ipad logged in to its google account already or is this all pre login?

 

Im running transparent, no auth for mine. i dont have those ports open specifically, i just set any to the meet media servers - probably should close that down but since google said theyre used exclusively for meet i was fine with it.

 

Ive just tried an explicit proxy and its still working, though i have no auth enabled on it.

 

These are the iOS apps so once logged in to any you're logged in to all. The Meet app opens fine, but always times out when trying to start a new instant meeting - which is the Drop entries in the log. The proxy is unauth and the other google apps (mail,drive etc) all work fine. Also, if you open Meet in the safari browser it works fine!

Edited June 1, 2021 by Sheridan

[DGardiner]

These are the iOS apps so once logged in to any you're logged in to all. The Meet app opens fine, but always times out when trying to start a new instant meeting - which is the Drop entries in the log. The proxy is unauth and the other google apps (mail,drive etc) all work fine.

 

Easy way to test it, add a no https inspect for all traffic from a location that contains the ip of your test ipad. see if that helps, then do the same in guardian all traffic, that location "whitelisted" and if its connects its not a firewall/port issue its a url somewhere being messed with.

 

Obviously, clean up after you have your results

[Sheridan]

I think that's the next thing to try. I've reinstalled the Meet app and it now doesn't offer the option to start a new meeting, only join an existing one, which suggests the newer version of the app disables this when it can't 'see' the route it needs.

[DGardiner]

I think that's the next thing to try. I've reinstalled the Meet app and it now doesn't offer the option to start a new meeting, only join an existing one, which suggests the newer version of the app disables this when it can't 'see' the route it needs.

 

Mind you just to add, I didnt NEED firewall exceptions for meet to work - opening the ports to the media servers just bypasses the proxy so improves meet quality/latency

[DGardiner]

Hmm, what I have setup is a rule to bypass https inspection for the google urls - including the ones you mention as well as the accounts. I also have a firewall rule to allow the https/19302-19309 ports out to the two google IP ranges as well

 

So the ipad has a smoothwall proxy/port set and therefore should use that - but it seems to hit the firewall on the a lot of the ranges I listed above, suggesting its ignoring the proxy setting altogether.

 

A snippet from the firewall log shows that its trying to access https for ranges out of the 2 google specify - and its blocked by the default rule (correctly!)

 

[ATTACH=CONFIG]62008[/ATTACH]

 

 

yeah that looks a bit off - Like its not respecting the proxy, is your smoothwall not in a position to do transparent proxy?

 

and presumably there is no entry for the destination/source in proxy exceptions as this would make the transparent proxy not pickup the traffic and thus hit the firewall

[Sheridan]

I'd have to a few changes to switch to a transparent proxy, but its only the Meet app that has a problem with it - it seems to just ignore the proxy