Create a Post
Showing results for 
Search instead for 
Did you mean: 

SmartConsole Log Query: using wildcards to find DNS resolved FQDNs

Is there a way to filter the Log in SmartConsole on destinations based on the DNS reverse lookup FQDN? I can always see successfully resolved reverse DNS lookups on results in the log in general, so I was hoping there is a way I could do something akin to "dst:*whatsapp*" to find all the destinations that resolve with "whatsapp" in the FQDN.

Why this is important:

Since WhatsApp sucks and their support team refuses to define an IP range for their servers, there is no way to create an allow rule with a destination range that is specific to their infrastructure.

Within the last three weeks said WhatsApp servers seem to no longer allow the iOS WhatsApp application to fall back from TCP/5222 to TCP/433 retaining working push notifications and a constant connection for text chat. It has worked for YEARS with no policy changes specific to it.

Since a, shall we say, VIP employee, needs to keep in touch with family in Europe, I suddenly need to set up a rule for allowing Jabber TCP/5222 outbound from our WIFI subnet..  Restricting it to his phone or a group of phones as a source is relatively easy.. But I need to restrict the destination as best as I can as well.

I was forced in the short term to create a rule that has the source as the VIP employee's host object (defined with the reserved IP address) and destination as ANY.. I HATE ANY... 

Discovered that Jabber was being being dropped from his phone destined for a particular FQDN in a subdomain during the testing today. I was unfamiliar with WhatsApp ports and what is required, so I assumed that either WhatsApp just started using TCP/5222 in their app, or for some reason, some Application Control policy received a CheckPoint update that suddenly blocked that port.. But the logs showed the Cleanup Rule was the reason for the drop.

Then queried on that specific destination whatsapp FQDN's IP address and found that jabber (5222) has been actively dropped for as far back as the logs go.. So the fact that the VIP's  WhatsApp and one other user's had been working fine on our Wifi up until 3 weeks ago suggests that something about the way the app or the server side works had changed..

Anyway, I wanted to find as many destination IPs that resolve to a FQDN with whatsapp in the name, so perhaps I could create a group containing all the IP addresses I found searching backward through the logs... and set that as the destination for the rule instead of ANY...  Sure sometimes he might come to me saying "My WhatsApp is hanging on 'Connecting' again, Chris!" and I would have to add another IP to the group, but at least I would stick to keeping the policy as restrictive as possible.. As XMPP has exploits..

Lots of googling, and searching here and nothing seems to address how to do a Smart Console Log query that filters on the reverse DNS lookup name of a destination.

I got lots of hits on why it is a bad idea to set up a RULE that is based on FQDN wildcards, but nothing about something as seemingly obvious as trying to find destinations with a given phrase in the FQDN.

I realize this is probably difficult because I assume that interactively, the reverse lookup is performed as the log entries are rendered in the SmartLog UI.   But I would hope there would be a mechanism to have the log filter and perform the reverse lookups as it trawls the log...

Is this something doable?


And Happy 2023 to you all!


0 Kudos
3 Replies

What you are seeing in the logs is most likely a "live" FQDN resolved by the system as it is displayed.
I do not believe we store it in the logs, therefore it is not something you can search on.

And yes, it seems that Facebook^wMeta used to maintain such a public list:
However, it appears they only provide this list to "Mobile Partners" and the list is specific to that particular mobile provider.

Have you tried using the pre-defined application for WhatsApp?
This requires App Control (doesn't require HTTPS Inspection) and, with an explicit and focused rule, you might be able to figure out what IPs are being used and lock it down.
Or you can just allow "WhatsApp" from the relevant devices to destination "Internet" and call it a day.
Another idea might be to check the logs of your DNS server.

0 Kudos

Hey thanks for the quick Reply Dameon!

I am wrapping up at 9:55pm here at the office after a brain frying day, so I will revisit your suggestions when I am back at work on Tuesday.

Internet rather than ANY...  Didn't even know that was a thing.. And i have been using CheckPoint stuff since 2015.. lol.

Are you saying use the pre-defined application for WhatsApp for filtering the query? or creating the rule?

Again I am burnt.. Skipped lunch... And dinner....

And breakfast, come to think of it.. LOL.

Thanks again, I will try your suggestions. 

As always, you are the man.


0 Kudos

Use the pre-defined WhatsApp application for creating the rule.
"Internet" has always been an option in the App Control rulebase going back to R75.
You can also use the External zone as the destination as well (from R80.10), which may be more appropriate.

0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events