WhatsApp Issue with Web Protection

M.Hegazy,

create a web exception with this urls:

^([A-Za-z0-9.-]*\.)?whatsapp\.com
^([A-Za-z0-9.-]*\.)?whatsapp\.net
^([A-Za-z0-9.-]*\.)?50\.22\.19[2-9]\.
^([A-Za-z0-9.-]*\.)?50\.22\.2[0-5][0-5]\.

^([A-Za-z0-9.-]*\.)?whatsapp\.net\.?/

Here the image. In my case works. I use decrypt and scan on my XG.

Regards

Hi

i solved whatsapp application issue yesterday

i dont use "Any" as service

the problem solved when i added whatsapp application ports and both of them were working till this morning

but couple hours ago the QR code came to the surface again

any idea why this strange behavior from the firewall??

hey

i have contacted them yesterday and they replied to check log viewer and check if there is anything blocked by web protection filter

and i have replied with there is not anything blocked and clarified all steps i took in attempt to solve the issue but still waiting for there answer

please dont forget to feedback us with there reply

thank you

hello

sorry for bringing this thread up again

i was able to solve the problem one more time by add each category i want to block in separate rule inside the web policy

once i did it the whatsapp application worked smoothly without delay

try to do the same and let us know

thanks

Interesting, I had the same issue withe Whatsapp I disabled the pharming protection created exceptions and allowed the ports it worked for a while then the problem reappeared as you all said the log viewer doesn't help at all with this problem it is not showing any problem or error

I will try your method and let you know

great

try to do the same and let us know what happened

so I am not really making progress, thinking about opening a support case...

If have tried everything I could imaginge but still could not make any progress. error still occurs as soon as I activate web protection.

funnywhise those devices have a different error as soon as I deactivate the web policy, but that seems to be a different story.

I really dont have a this complicated setup, i am really getting frustrated with that xg.  and obviously some of the solutions are working for some of us, but not for others... really confusing and log files do not help at all.

anyone else making progress with that whatsapp piece of sh*t???

It is the WhatsApp application doing HTTP requests to a WhatsApp server.  It may not be following normal HTTP standards.

Can you try something:

Go into the console (not ssh shell).  So in the menu choose (4 Device Console).

show http
set http add_via_header off
set http relay_invalid_http_traffic on

Try again.  If it is still broken, please revert the changes.

Next thing would be to see if the problem is with other ports.  Are the ports listed here allowed through the firewall?

https://www.quora.com/What-is-the-port-number-for-whatsapp

Michael, thank you in advance! Will try that step by step.

How ist the console setting to be assessed in terms of security? I mean, filtering out invalid http traffic, if you dont, is this weaking security somehow?

Thanks a lot Michael

Getting back once I have testet both suggestions and found something new. Great forum support, thank you!

It can potentially decrease security because that traffic cannot be scanned.  Basically traffic that is using port 80/443 must conform to the HTTP standard for us to be able to scan the traffic.  This setting is basically if there is non-HTTP traffic or malformed traffic does it get blocked or allowed.

An example is a type of media streaming called icycast, not commonly used these days.

The HTTP standard is the client sends GET http://somesite and the server responds with 200 OK.

With an icycast, the client sends GET http://somesite and the server responds with 200 ICY.

That response does not conform to the HTTP standard and is therefore not allowed.  Turning this global option on would allow it.

so just to be sure, in order to undo the changes i have to:

show http
set http add_via_header on
set http relay_invalid_http_traffic off

correct?

Correct, that will set them back to their defaults.  Though it might now have been clear, when I wrote the original 

show http

that was so you could see and remember the currently set options before fiddling so you could return them back.

Correct, that will set them back to their defaults.  Though it might now have been clear, when I wrote the original 

show http

that was so you could see and remember the currently set options before fiddling so you could return them back.