mrstrong Posted May 12 Posted May 12 (edited) WhatsApp is being blocked, in web filter logs I see Group: Staff, HTML return code: 0 for URL: https://57.144.223.33 Categories: Social Networking, Facebook, Transparent HTTPS Incompatible Sites, WhatsApp Messenger On the Web Proxy under Transparent authentication policies this interface is set up to "Block HTTPS traffic with no SNI header" so maybe that is why it's returning 0 for the direct IP request? But the actual policy below for this interface (you can have several policies) has "Allow Transparent HTTPS incompatible sites and filter others using name from certificate" so it should work ? It's also set as No Authentication (Staff for unauthenticated requests) and WhatsApp Messenger Category is allowed for Staff (and we are not inspecting HTTPS). Edited May 12 by mrstrong
mrstrong Posted May 13 Author Posted May 13 Mmm, I tried to change interface Behaviour from "Block HTTPS traffic with no SNI header" to "Allow Transparent HTTPS incompatible sites and filter others using name from certificate". but drop down arrow is disabled. Also the interface Method is set to Core Authentication and I can't change it. Not sure why it is "Core Authentication" as there is only one policy with No Authentication (Staff for unauthenticated requests). Google is suggesting I bypass the proxy via Services > Web Proxy > Authentication > Exceptions "This forces Smoothwall to step completely out of the handshake path when staff devices reach for any Meta infrastructure, removing the SNI validation check entirely" Does that sound correct ? Or is it worth just trying to delete this interface and re-create as No Authentication (Staff for unauthenticated requests) with "Allow Transparent HTTPS incompatible sites and filter others using name from certificate" ?
mrstrong Posted May 21 Author Posted May 21 bump. nobody allowing whatsapp through smoothwall ? just having another look and it seems to be just a few IPs getting denied e.g. 31.13.73.53 57.144.253.33 57.144.223.33 I deleted the interface and created a new policy as No Authentication (Staff for unauthenticated requests) with "Allow Transparent HTTPS incompatible sites and filter others using name from certificate" but interface is still showing as "Block HTTPS traffic with no SNI header" 😕
bknaggs Posted May 21 Posted May 21 WhatsApp works on our Staff BYOD. We don't inspect https there but I'll have a look and see if I've had to do anything out of the ordinary to allow it. 1
bknaggs Posted May 21 Posted May 21 I can't see any Smoothwall rules specifically allowing WhatsApp for staff. I do have a couple of outbound firewall rules allowing TCP 5222 and 5223 and UDP 3478 outbound from our BYOD VLAN.
synaesthesia Posted May 21 Posted May 21 Yes, it's very nasty with HTTPS inspection - I couldn't ever get it to work, only would when inspection was removed.
mrstrong Posted May 21 Author Posted May 21 yes i got those firewall rules set up but its the web filter / proxy dropping it I think e.g.: I think because interface has "Block HTTPS traffic with no SNI header" even though I deleted that interface and created a new policy (with "Allow Transparent HTTPS incompatible sites and filter others using name from certificate" But interface is still showing as "Block HTTPS traffic with no SNI header". Interface: Policy: This is also a BYOD network for guests so not doing HTTPS inspection
mrstrong Posted May 22 Author Posted May 22 just had a thought, perhaps as there is another VLAN on Port 2 it won't let me change the "Block HTTPS traffic with no SNI header" on the interface to "Allow Transparent HTTPS incompatible sites and filter others using name from certificate". I'd have to delete both and re-create ? Or perhaps I could just create category with whatsapp IPs and "allow" them just for staff on this VLAN ?
tom_newton Posted May 26 Posted May 26 I'd go for allowing the IPs, and exempting them from filtering. As it's staff, the risk is low. Whatsapp is a pain.
timbo343 Posted May 26 Posted May 26 Ive been looking at this myself as we ran into issues just recently too. It seems tbat WhatsApp change their IPs quite frequently so we have added WhatsAppMessenger category to a Do Not Filter rule on our BYOD abd Guest networks, along with a HTTPS Do Not Inspect rule too. We checked to make sure that the WhatsApp Ports were all unfiltered also. I'm presumming *.whatsapp.com and *.whatsapp.net are in the WhatsApp category provided by and updated by Smoothwall. It's a shame we cannot do domain and port blocking / allowing on the firewall of a Smoothwall device 🙃 Taken for sources on the net: Essential Ports TCP: 80 and 443 (General HTTP/HTTPS traffic and secure communication) TCP: 5222 (Primary XMPP connection port for chat messages) UDP & TCP: 3478 (STUN port used for voice and video call setup) Media & Advanced Calling Ports If users are experiencing dropped calls or media failure, you may need to add the following ports to your outbound firewall policies: TCP: 4244, 5223, 5228, 5242, 59234, 50318 UDP: 45395, 59234, 50318, 41285, 49984 Best Practices Domain Whitelisting: WhatsApp frequently changes its IP addresses. Network administrators are advised to whitelist *.whatsapp.com and *.whatsapp.net in URL and web filters 1
MatthewL Posted May 26 Posted May 26 If you can specify a URL for your locations you can use this one https://adamnetworks.dev/pub/fwaliases/raw/master/ips/whatsapp.txt then these ports a mix of TCP & UDP
tom_newton Posted May 27 Posted May 27 Whatsapp doesn't do DNS lookups - I'm doing some work with one of the best DNS firewalls out there, they have to have a static IP sig for whatsapp too
mrstrong Posted June 4 Author Posted June 4 (edited) just fyi, our whatsapp now looking healthy again on guests network (no https inspection) All that was needed was a "Do Not Filter" action on the "WhatsApp Messenger" category (plus firewall allow XMPP etc) easy when you know how, thanks @timbo343 No need for a new category as e.g. https://57.144.223.33/ matches the built-in "WhatsApp Messenger" category via "URL patterns" So I think smoothwall must be mantaining this 🤞 Edited June 4 by mrstrong added more detail 2 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now