URL permitidas

[Fabrizio]

Tengo varios equipos que    los tengo normal en tema de Device policy, la cual podian abrir https://web.whatsapp.com/,

de ayer para hoy dejo de funcionar, cambie la politica del usuario a permitir todo, y volvio a jalar.

Tengo en las URL permitidas https://web.whatsapp.com/. se supone que debería de jalar.

Alguien mas tiene ese problema, a mi ya me había pasado, y después de una semana se volvió acomodar solo.

[alemabrahao]

I suggest you open a support case.

[BrandonD]

Hi @Fabrizio,

Thanks for the community post :).

I tend to agree with @alemabrahao, given the inconsistent nature this likely seems best troubleshot over a live call/case review - process outlined below for contacting support:

• https://documentation.meraki.com/General_Administration/Support/Contacting_Support

That being said, without reviewing the existing blocked URLs list I just wanted to call out the 'logic' behind the URL filtering for reference:

Whenever a client fetches a web page on this network, the requested URL is checked against the lists configured below to determine if the request will be allowed or blocked.

Pattern matching follows these steps:

1. Check if the full requested URL is on either list.
   • example: https://web.whatsapp.com/ 
2. Cut off the protocol and leading "www" from the URL, and check if that is on either list: web.whatsapp.com
3. Cut off any "GET parameters" (everything following a question mark) and check that: foo.bar.com/qux/baz/lol (not relevant to your displayed configuration) 
4. Cut off paths one by one, and check each:foo.bar.com/qux/baz, thenfoo.bar.com/qux, thenfoo.bar.com
5. Cut off subdomains one by one and check those:bar.com, and then com
6. Finally, check for the special catch-all wildcard,*, in either list.

If any of the above produces a match, then the request will be allowed through if it is in the allow list and blocked otherwise. (That is, the allow list takes precedence over the block list.)

If there is no match, the request is allowed, subject to the category filtering settings above.

HTTPS requests can also be blocked. Because the URL in an HTTPS request is encrypted, only the domain checks will be performed (www.foo.bar.com,foo.bar.com,bar.com,com, and the special catch-all *).

In short, the preferred method of allowing all of the 'whatsapp.com' would be simply whatsapp.com and without an asterisk (this would include HTTP & HTTPS requests.) This assumes no URL redirects are causing issues in a secondary domain.  

For added context please see below:

• https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering#Using_...

Thanks and hope this helps!