when ever i turn on web protection for a rule users who can use internet through this rule can use whatsapp application on there phones or web whatsapp
i tried to make a workaround for web whatsapp and created a top rule that allow access to web whatsapp and turned off web protection and that solved web whatsapp problem
now my problem is with the application it self it wont work until i turn off the web protection
although i made exception for it in the PROTECT>Web>Exceptions and checked the log viewer and it is all green and all http and https scan & Decrypt are turned off
is there any solution for this issue ?
create a web exception with this urls:
Here the image. In my case works. I use decrypt and scan on my XG.
UTM Certified Architect - XG Certified Architect
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??
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 httpset http add_via_header offset 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?
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 httpset http add_via_header onset http relay_invalid_http_traffic off
Correct, that will set them back to their defaults. Though it might now have been clear, when I wrote the original
that was so you could see and remember the currently set options before fiddling so you could return them back.
set http add_via_header offset http relay_invalid_http_traffic on
it did not work, unfortunately, this morning i had the same circumstances.
dumb question: if i allow services "all" in firewall rules, do I have to open specific ports additionally somewhere? just to ensure that I am doing it correctly...
Service All basically means every port. Effectively allowing Service All means the firewall starts allowing everything and no longer protects as a firewall should.
Useful for debugging, horrible for security. Its like getting a really expensive deadbolt for your front door and then leaving your door wide open. :)
Thank you, then I'd been right. For testing purposes I moved all WiFi Clients into a separate VLAN with its own Firewall rule on that VLAN. Therefore I allowed all services so unfortunately this does not seem to be my solution either.
Michael, do you think this could be related to my VLAN Setup? According to my logs I also had some default Drops (rule ID 0) with "Could not assocate packet to any connection"
Thank you for everthing so far.
Additionaly: I am testing with our Aruba Access Points at the moment, using a SSID that does not support Roaming accross other APs. Maybe something happens to the session during roaming and Sophos stumbles upon that. Just to exclude the Aruba I'll give that a try. Keep you updated.
My recommendation from Sept 1 still stands.
1) You have done a bunch of work to diagnose. It is very hard for people in the forums to diagnose. It is easier for Sophos Support to since you can give them direct access to your system. Raise a ticket and pester them.
2) Use firewall rules to bypass the proxy just for these connections. Create FQDN Host objects for all of the whatapp domains and then put in a high level rule the has them as the destination, service any. Traffic that is not for WhatsApp still uses your regular firewall rule with web proxy.
I finally, after months, solved the issue:
Go to Web Protection -> Generall Settings -> HTTPS decryption and scanning and then UNCHECK "Block unrecognized SSL protocols"
Somewhere I read about Whatsapp using invalid SSL. Thats the point here. Wished my firewall had more clear logfiles. Impossible to work with the logfile to solve this. Thats the sad point. The lucky point is, it is working :) :) :) Finally! ;)
Works with pharming protection on, btw. And I dont need any exceptions. You can leave "Block invalid certificates" checked.
One year later and the beginning of this week whats-app stopped working over our XG , and this was the only thing I found that fixed it. Thank you.