Thread Info
  • State Verified Answer
  • +5 person also asked this people also asked this
  • Locked Locked
  • Replies 56 replies
  • Answers 4 answers
  • Subscribers 42 subscribers
  • Views 272666 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WhatsApp Issue with Web Protection

M.Hegazy

hello everyone 

 

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 ?

thank you 



This thread was automatically locked due to age.
  • 0 in reply to Michael Dunn

    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!

  • 0 in reply to Michael Ploch1

    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.

  • 0 in reply to Michael Dunn

    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?

  • 0 in reply to Michael Ploch1

    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.

  • 0 in reply to Michael Dunn


    set http add_via_header off
    set 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...

  • 0 in reply to Michael Ploch1

    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.  :)

  • 0 in reply to Michael Dunn

    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.

  • 0 in reply to Michael Ploch1

    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.

     

     

  • +2

    Hi guys,

     

    That way i solved the problem of Whatsapp not working properly behind a Sophos UTM 9.x

     

    1. READ UNTIL THE END!!!

    2. Go to: NETWORK PROTECTION - FIREWALL

    3. Add a new rule that looks like:  from "Internal Network" - service "whatsapp" - to "any"

        You drag and drop these three categories from the left side of the menu to the right side. "whatsapp" is a preconfigured setting provided by the Sophos UTM.

        Save it, activate it. 

        I use the transparent proxy mode. Pharming protection enabled.

     

    4. Add a new rule that looks like: from "Internal Network" - "TCP 5222, TCP 5223, UDP 3478" - to "any"

        That rule was key for making my setup work completely. Without, only chat worked but calls only between devices on my LAN.

     

    5. I´v added this rule but I am not 100% sure if it is really necessary after 4.):

        First, I did a static address mapping for my IOS devices as these are the only ones I use for Whatsapp video/ audio calls and chats. 
        I want only my IOS devices being allowed to use Whatsapp so that no attacker from outside could get through to my NAS, printer or any other devices not intended to use Whatsapp.

        Also, Whatsapp calls initiated from a device within my LAN should work to any other Whatsapp user, may he be on the web or in my LAN, too.

        Therefor I added a new rule that looks like: from "Any" - "whatsapp" - to: <here I selected all my IOS devices that show up in the left selection menu>

     

    6. ACTIVATE all these rules with the activation button!

     

     

    Whatsapp chats via webbrowser from my PCs work.

    Whatsapp chat now works fast, audio and video calls work from my IOS devices, too.

     

    Good luck and my you save a lot of time that I had to put in...

    BR Alex.

  • 0 in reply to Alexander Weinbacher

    I thought this was for XG, not UTM?