WhatsApp messages will not send - but calls work
-
Hello,
I've been struggling with issues sending/receiving WhatsApp messages while connected to my network, yet WhatsApp phone calls/video calls work fine. Additionally, when I connect to a VPN service (PIA) the messages immediately update and send/receive freely... this seems to indicate I have some kind of setting or service on pfSense that's blocking the messages.
I'm running Snort (connectivity setting) and pfBlocker NG - but I've been running those for some time now and the message blocking is recent.
I'm still really new with this level of firewall control - what do I need to be checking to source the problem? What troubleshooting should I be trying?
I really appreciate any recommendations you can offer!
Thank you - -
@BCMguy said in WhatsApp messages will not send - but calls work:
Hello,
I'm running Snort (connectivity setting) and pfBlocker NG - but I've been running those for some time now and the message blocking is recent.Troubleshooting 101. When running packages that block things (Snort and pfBlockerNG, for example) and something mysteriously stops working, the very first step is to check the alerts from those packages and see if any apply to the IP addresses associated with your problem. In this case do you see alerts in Snort or pfBlockerNG where the IP addresses match either the IP of the device you are using for WhatsApp (phone or tablet) or the IP addresses associated with WhatsApp servers?
-
Thank you,
No alerts thus far. Snort doesn't alert on much the way I have it configured, and I've not noticed anything matching yet on pfblocker. After a period of time the messages will send.
What's odd too is I've tried disabling both snort and pfblocker and that didnt seem to allow messages to send either. I feel like the problem has to be something else... -
Upon further study it looks like it's coming from snort - "snort2c hosts".
The learning and research continues.
-
This post is deleted! -
Run whatsapp all day every day. Chat and calls. To inside and outside destinations. It always works. It must be something you have done to break it.
-
Thank you everyone - I've cleared out some Facebook IPs from the snort2c list and it looks like that's restored functionality. Took me a bit to find the right places to look to find the blocking. I wasn't getting snort alerts because it was being handled by the firewall directly via the snort2c table.
-
@BCMguy said in WhatsApp messages will not send - but calls work:
Thank you everyone - I've cleared out some Facebook IPs from the snort2c list and it looks like that's restored functionality. Took me a bit to find the right places to look to find the blocking. I wasn't getting snort alerts because it was being handled by the firewall directly via the snort2c table.
You can never get a block from Snort that Snort does not alert on first. Now, if you have tons of alerts and/or have your alert log size limit set very small, it is possible for the alert entry to wind up in a rotated alert log and thus it won't show on the ALERTS tab because that tab only shows alerts from the active log (it does not go look into rotated logs).
The snort2c table you refer to is populated by Snort using a FreeBSD system call. So any IP address in that table can only have come from Snort (nothing else writes to that table assuming you don't also have Suricata running as it shares that same table). In fact, that table is how Snort blocks. It puts the IP address to be blocked in that table via the FreeBSD system call. The table is created solely for Snort to use (hence the table's name). When you view blocked hosts on the BLOCKS tab, the GUI is dumping the contents of the snort2c table to the screen.
The recommendation is the set the "Remove Blocked Hosts Interval" to a reasonable value of 1 hour or less. This will let the associated cron task automatically remove blocked hosts from the snort2c table when that host has not seen repeat traffic within the interval entered. For some reason never understood by me (the package maintainer, some folks think NEVER is the best choice for this parameter. It is not. Use a short interval like one hour tops or less for this parameter.
