problem with whatsapp and squid proxy server
-
hello everyone, I come here to request your help and I spent years trying to solve this problem but I can't find any solution
I have squidproxy server configured in transparent mode, ssl enabled splice all to pass everything to squidguard
I tried to unblock whatsapp anyway but I can't do it.
I always get:
NONE_NONE_ABORTED/000 http://c.whatsapp.net/chat - -
in all the white lists of squidserver, squidguard, firewall rules this whatsapp and its domains, including meta and facebook but the error is always presented :(I read in a forum from years ago and in Portuguese that when I turned off clamav and c-icap it worked and indeed if I do it it works perfectly
and I receive:
TCP_MISS/200 http://c.whatsapp.net/chat - 157.240.14.53
and I no longer have any problem but at the same time I am left unprotected if antivirus over http wanted to make it functional even with clamav and c-icap active, I decided to edit squidclamav.conf and put the c.whatsapp.net domain as a whitelist so that it does not analyze or anything but I get the unwanted result again
NONE_NONE_ABORTED/000 http://c.whatsapp.net/chat - -
and the messages are waiting to be sent and I send them every 15 min with luck or I receive every hour -
@ntranx honestly, I suggest to buy a AV are cheap and have support from a company, if u have a issue who from clamav will support u?
Regards. -
currently i am using yo whatsapp plus and facing the same problem, can you help me
-
The way I solve this, is by implementing my own NAT rules to control what TCP connexions are fed to Squid with more granular control. This is how I do it.
-
Create a structure of aliases for bypass. In my setup, I use this hierachy:
-BYPASS_SQUID (type host, it is an aggregate of my aliases of other types)
-BYPASS_SQUID_NET (type network, I enter CIDRs I want to bypass. It contains both public CIDRs, and a list of local subnets including the firewall webUI address).
-BYPASS_SQUID_FQDNS (type hosts, I use it to enter hostnames, this is where I have c.whatsapp.net defined!) -
Create NAT rules to feed Squid. I suggest 1 NAT rule for HTTP, and another for HTTPS. By default, squid listen on 3128 for HTTP and 3129 for HTTPS In my lab, it looks like this:
Using port forward rules, the trick is to redirect all the clients you want to interception but invert the match on destination IP. So that if a TCP connexion arrives at the firewall for these destinations, it is simply NATed and never seen by Squid, at all.
-
Now that you are using your own NAT rules for transparent interception, you'll want Squid to exclude the subnets by default so that you manage everything through the NAT rules you just created, in a single place. This is done in Squid General settings, "Bypass Proxy for These Source IPs": add your local subnets in there so that the default rules created by Squid won't match anything in your environment.
If you wanted, you could have different Bypass lists for HTTP and HTTPs. I am personally happy with this solution. I am not seeing the traffic to c.whatsapp.com in my squid access log but I don't care, I get everything else. That's good enough for me.
I hope this helps.
-
-
@vlurk said in problem with whatsapp and squid proxy server:
c.whatsapp.net
I got a little lost, I understand that I create the Alias with the host c.whatsapp.net then with this alias I create a nat for http and https in their respective squid ports and then? I'm already lost
-
I think you got lost between point 2 and 3, because there isn't much. Unfortunately, you are not telling me what you don't understand. So I'll resume.
1-Create an alias that contains all the destination IP address you need to bypass. I think you understood that part.
2-Create your own NAT rules to intercept traffic, where you invert (don't match) the destination IPs. In effect, it means c.whatsapp.net will not match the rule and thus, will not get intercepted. Look at my screenshot I shared earlier if you are not sure about the NAT rule. Notice that in destination, I have an exclamation mark besides the destination alias. I can take a screenshot of the rules detail if that's what you are struggling with.
3- In Squid General Settings, add your subnets or at least the hosts that needs to bypass stuff using the NAT rules you created. There's a field for that: Bypass Proxy for These Source IPs". If you don't do that, traffic for the hosts you want to bypass can still hit the default NAT that is being silently created by the package, and c.whatsapp.net would thus still be intercepted. You probably don't want to rely on that default rule at all, and it's more useful to just control what gets fed to Squid using your own custom NAT rules as it provides more flexibility.That's it. There is literally nothing else. It's just that simple.
-
@vlurk Ok, I tried to do it as I mentioned but I think I was wrong about something.
I made the alias with the WhatsApp domains and placed it in NAT as its test image (I tried to put ! before the alias but it won't let me) each NAT rule directed to 127.0.0.1 with its respective port and then in squid I put the ips to I skipped using the alias again but I always keep getting the error.
-
and the NAT
-
@ntranx See, your NAT rules are not correct. You are instructing the firewall to send everything matching your alias to Squid. Which means c.whatsapp.net. But you want to do the opposite. You did not invert the match on the destination: that is precisely why I asked you to look for the exclamation mark, ensuring you did not forget to invert the match.
This is what you are missing:
The checkbox means "everything that will not match the alias". Which means in the end, you will be forwarding everything but whatsapp.
-
@vlurk you are right it is really awesome this solved my problem
-
@vlurk but I will tell you that after a while, it starts to crash again and I don't understand why squid keeps seeing the host.
-
@ntranx said in problem with whatsapp and squid proxy server:
@vlurk but I will tell you that after a while, it starts to crash again and I don't understand why squid keeps seeing the host.
The reason is that c.whatsapp.net is hosted in Amazon AWS, and the service is using DNS load balancing. At some point, the client will try to connect to some IPs that are not matched by the firewall alias. So Squid will intercept the traffic, as per design. FQDN should be good to match most of the connections, but some are going to fail at times. It is inevitable in such a scenario. Even if you make sure your clients only use the local resolver.
If you'd like to have this working 100% of the time, with 0 interruption ever, you'll need to step up your game. As I did. Now that you understood the logic behind the NAT rules, it would be the right time.
For a production environment, I am leveraging pfBLockerNG to synchronize lists of subnets. One of the lists I synchronize with is AWS. The URL of that list is: https://ip-ranges.amazonaws.com/ip-ranges.json
It may be a json dataset, but current version of pfBLockerNG is totally capable of parsing this file.If you bypass all the IPs from that list, it is going to include c.whatsapp.net, all the time. As well as many, many other web services that are likely going to fail eventually for the same reasons (DNS load balancing). If there is ever a domain hosted on AWS that I want blocked, I leverage DNSBL at that point. I do this for several CDNs (such as Akamai) and cloud-based services (like skype/teams, Azure Front Door) to ensure everything works all the time, and get rid of the infamous 409s with dns records that have short-lived TTLs.
-
@vlurk
I tried to do this but the result was the same and I started to have more problems on my network with other devices, so I decided to leave squid in transparent mode for http and uninstall squidguard, and in squid I did not activate ssl; For https filtering I do it with pfblockerNG which updates with thousands of blacklists and the update is done with the period of time I want. Therefore, if you are not going to perform an exhaustive analysis of the certificate, I recommend this scenario.
