Whatsapp taking long time "Connecting" and not receiving new notifications

[Dave]

We are providing guest wifi access and do application and url filtering.

Most of the stuff we want to allow is working, only Whatsapp exhibits not fully functional behaviour.

Every time you open the app on your phone, it will be "Connection" for quite some time, after being patient for a while you can start sending messages, but because of this behaviour users are not receiving any notifications when new messages arrive.

This leads me to believe the connection gets cut when you push the app to the background or lock your phone and it needs to reestablished.

Users now only see new messages when they are actively using Whatsapp.

Is there a way to go around this and solve so new messages will pop up on your screen when arriving?

[Maarten_Sjouw]

Did you add the WhatsApp application in an allow rule? Keep in mind that it uses another port on top of http(s): 4244, 5222, 5223, 5228 and 5242

[Dave]

Yes we have added WhatsApp to the application layer policy, allowing it and all ports you mentioned.

[Maarten_Sjouw · Accepted solution]

You need to allow the ports in the access policy for it to work.

[Dave]

It actually is working, that's not the problem, the issue is that it seemly takes a long time to connect to the WhatsApp servers and the push messages don't come true.

You will only see your messages when you have the app opened up, having waited a while till connections established.

I did a packet capture of my phone and saw a lot of this stuff:

(replaced my actual ip with iPhone)

11:34:12.629453 IP iPhone.60740 > 169.47.40.153.xmpp-client: S 3358543405:3358543405(0) win 65535
11:34:12.738939 IP iPhone.60741 > 198.11.251.41.xmpp-client: S 2982904855:2982904855(0) win 65535
11:34:12.845064 IP iPhone.60742 > 169.54.55.206.xmpp-client: S 3671419622:3671419622(0) win 65535
11:34:12.951613 IP iPhone.60743 > 169.45.248.111.xmpp-client: S 3117870734:3117870734(0) win 65535
11:34:13.636062 IP iPhone.60740 > 169.47.40.153.xmpp-client: S 3358543405:3358543405(0) win 65535
11:34:13.740114 IP iPhone.60741 > 198.11.251.41.xmpp-client: S 2982904855:2982904855(0) win 65535
11:34:13.846590 IP iPhone.60742 > 169.54.55.206.xmpp-client: S 3671419622:3671419622(0) win 65535
11:34:13.952681 IP iPhone.60743 > 169.45.248.111.xmpp-client: S 3117870734:3117870734(0) win 65535
11:34:14.637483 IP iPhone.60740 > 169.47.40.153.xmpp-client: S 3358543405:3358543405(0) win 65535
11:34:14.741861 IP iPhone.60741 > 198.11.251.41.xmpp-client: S 2982904855:2982904855(0) win 65535
11:34:14.848089 IP iPhone.60742 > 169.54.55.206.xmpp-client: S 3671419622:3671419622(0) win 65535
11:34:14.953561 IP iPhone.60743 > 169.45.248.111.xmpp-client: S 3117870734:3117870734(0) win 65535
11:34:15.637951 IP iPhone.60740 > 169.47.40.153.xmpp-client: S 3358543405:3358543405(0) win 65535
11:34:15.744217 IP iPhone.60741 > 198.11.251.41.xmpp-client: S 2982904855:2982904855(0) win 65535
11:34:15.849819 IP iPhone.60742 > 169.54.55.206.xmpp-client: S 3671419622:3671419622(0) win 65535
11:34:15.955960 IP iPhone.60743 > 169.45.248.111.xmpp-client: S 3117870734:3117870734(0) win 65535

[Dave]

11:34:22.640208 IP iPhone.60744 > 169.47.40.153.https: S 2483236132:2483236132(0) win 65535
11:34:22.721945 IP 169.47.40.153.https > iPhone.60744: S 299610087:299610087(0) ack 2483236133 win 65535
11:34:22.805006 IP iPhone.60744 > 169.47.40.153.https: . ack 1 win 2058 <nop,nop,timestamp 1048844764="" 2208893636="">
11:34:22.828612 IP iPhone.60744 > 169.47.40.153.https: P 1:264(263) ack 1 win 2058 <nop,nop,timestamp 1048844787="" 2208893636="">
11:34:22.885688 IP 169.47.40.153.https > iPhone.60744: . ack 1 win 16385 <nop,nop,timestamp 2208893800="" 1048844764="">
11:34:22.939221 IP 169.47.40.153.https > iPhone.60744: . ack 264 win 16385 <nop,nop,timestamp 2208893854="" 1048844787="">
11:34:23.003232 IP 169.47.40.153.https > iPhone.60744: P 1:58(57) ack 264 win 16385 <nop,nop,timestamp 2208893917="" 1048844787="">
11:34:23.003344 IP 169.47.40.153.https > iPhone.60744: P 58:104(46) ack 264 win 16385 <nop,nop,timestamp 2208893917="" 1048844787="">
11:34:23.005850 IP iPhone.60744 > 169.47.40.153.https: . ack 58 win 2057 <nop,nop,timestamp 1048844961="" 2208893917="">
11:34:23.005862 IP iPhone.60744 > 169.47.40.153.https: . ack 104 win 2057 <nop,nop,timestamp 1048844961="" 2208893917="">
11:34:23.016901 IP iPhone.60744 > 169.47.40.153.https: P 264:306(42) ack 104 win 2057 <nop,nop,timestamp 1048844973="" 2208893917="">
11:34:23.019482 IP iPhone.60744 > 169.47.40.153.https: P 306:352(46) ack 104 win 2057 <nop,nop,timestamp 1048844975="" 2208893917="">
11:34:23.046817 IP iPhone.60744 > 169.47.40.153.https: P 352:382(30) ack 104 win 2057 <nop,nop,timestamp 1048845002="" 2208893917="">
11:34:23.048593 IP iPhone.60744 > 169.47.40.153.https: P 382:441(59) ack 104 win 2057 <nop,nop,timestamp 1048845002="" 2208893917="">
11:34:23.061064 IP 169.47.40.153.https > iPhone.60744: P 104:152(48) ack 264 win 16385 <nop,nop,timestamp 2208893975="" 1048844787="">
11:34:23.061818 IP 169.47.40.153.https > iPhone.60744: P 152:184(32) ack 264 win 16385 <nop,nop,timestamp 2208893976="" 1048844787="">
11:34:23.062621 IP iPhone.60744 > 169.47.40.153.https: . ack 152 win 2056 <nop,nop,timestamp 1048845017="" 2208893975="">
11:34:23.064427 IP iPhone.60744 > 169.47.40.153.https: . ack 184 win 2056 <nop,nop,timestamp 1048845017="" 2208893976="">
11:34:23.073867 IP iPhone.60744 > 169.47.40.153.https: P 441:812(371) ack 184 win 2056 <nop,nop,timestamp 1048845027="" 2208893976="">
11:34:23.100382 IP 169.47.40.153.https > iPhone.60744: . ack 352 win 16384 <nop,nop,timestamp 2208894015="" 1048844973="">
11:34:23.129412 IP 169.47.40.153.https > iPhone.60744: . ack 441 win 16384 <nop,nop,timestamp 2208894044="" 1048845002="">
11:34:23.161033 IP 169.47.40.153.https > iPhone.60744: P 184:218(34) ack 812 win 16385 <nop,nop,timestamp 2208894075="" 1048845027="">
11:34:23.163422 IP iPhone.60744 > 169.47.40.153.https: . ack 218 win 2055 <nop,nop,timestamp 1048845115="" 2208894075="">
11:34:23.193485 IP 169.47.40.153.https > iPhone.60744: P 218:267(49) ack 812 win 16385 <nop,nop,timestamp 2208894107="" 1048845027="">
11:34:23.193553 IP 169.47.40.153.https > iPhone.60744: P 267:543(276) ack 812 win 16385 <nop,nop,timestamp 2208894108="" 1048845027="">
11:34:23.196116 IP iPhone.60744 > 169.47.40.153.https: . ack 267 win 2054 <nop,nop,timestamp 1048845147="" 2208894107="">
11:34:23.196126 IP iPhone.60744 > 169.47.40.153.https: . ack 543 win 2050 <nop,nop,timestamp 1048845147="" 2208894108="">
11:34:23.218003 IP 169.47.40.153.https > iPhone.60744: P 543:580(37) ack 812 win 16385 <nop,nop,timestamp 2208894132="" 1048845027="">
11:34:23.221150 IP iPhone.60744 > 169.47.40.153.https: . ack 580 win 2049 <nop,nop,timestamp 1048845172="" 2208894132=""></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp>

[Maarten_Sjouw · Accepted solution]

The XMPP client not getting any response is what you are looking for, all you see there is SYN packets no response, so you will see drops in your logs for the source and destination combo, as it does not allow those ports. 5222/5223

[Dave]

Thanks for your input Maarten, i hope we're getting there bit by bit 🙂

As you can see from the second part of the packet capture, the ACK's are coming true for one particular server.

I also have to note that this is an iPhone specific issue because Android users don't have any and works like a charm.
They open WhatsApp and don't have to wait for it to connect, also they just keep receiving messages notifications without any problem.

[Dave]

Hi Maarten,

I had indeed something to do with TCP port 5222 and 5223, still the app showed some strange behaviour before implementing the solution as it worked but only no push messages received until you actually opened up the app manually.

So what i did was i created separate TCP/UDCP port objects for all WhatApp ports concerend and add all of them into a newly created Services Groups.
I then added this new Services Group to the concernd access policy rule where guest access is allowed, pushed the policy.

BOOM! All working and push messages coming in, no more "Connecting" message either when opening WhatsApp!

Still, it puzzles me why it was working so-so before implementing this, as i didn't saw any drops in the logging.

Many thanks for the help and guidance!

[Timothy_Hall]

Hi Dave,

Assuming you are using R80.10+, could the reason that you didn't see the drop logs you were expecting for 5222/5223 was because an "early drop" for that traffic occurred due to the new Column-based matching algorithm?

sk111643: Early drop of a connection before the final rule match