Cato Networks Knowledge Base

Why Do Connections Destined for the Same Server Receive Different (Block/Allow) Action from Cato?

  • Updated


This article describes the reason why, despite going to the same destination, certain connections are blocked by Cato while others are allowed.

For example, the event discovery below illustrates instances where the same source attempted to connect to the same destination IP on the same protocol. However, while one connection was blocked, the other was allowed.



In this section, we will explore several common scenarios that may cause the connection to be treated differently by Cato. Understanding these scenarios is essential for optimizing and troubleshooting the connection effectively. Let's delve into each of them below.

1. Asymmetric Routing

When Cato doesn't have visibility into the complete flow, it might lack sufficient information to accurately categorize the data into the appropriate application. Consequently, even if there is a firewall rule permitting a specific protocol like HTTPS, asymmetric routing could lead to the flow being mistakenly categorized as TCP. Unfortunately, this misclassification can result in the connection being blocked since it doesn't align with the allowed firewall rule. To investigation further, it's recommended to perform a traceroute from both the source to the destination and vice versa when the issue is occurring. By comparing the forward and reverse paths, we can validate if this indeed is the cause of the problem.

2. Overlapping Custom Application

When dealing with an affected connection that involves a custom application, it is crucial to conduct a thorough examination of its definition. An overly simplified definition of a custom application could cause Cato to inconsistently identify the application. If there is a Firewall Rule permitting connections to the custom app, but due to how the custom app was defined, its identification becomes inconsistent, resulting in intermittent blocking of the connection. Therefore, when dealing with connections destined for custom applications, we recommend following the best practices outlined in Working-with-Custom-Applications to ensure consistent behavior.

3. SDP User vs User

The distinction between SDP users and Users in the rule can sometimes cause confusion.


The term "SDP User" refers to users who connect to Cato through their Cato VPN Client application, while "User" denotes regular users behind a socket site. If SDP Users behind the socket site have Office Mode enabled, they are also considered "Users" as they connect to Cato through the socket instead of using the Cato VPN Client application.

Understanding this distinction is crucial when creating Firewall and/or Network Rules. For instance, in the following Firewall Rule, "test-user" is allowed access to, while all other connections are blocked.


However, when the SDP user with the username "test-user" attempted to access, the connection was blocked. This occurred because the specific allow rule was intended to grant access to regular users with the username "test-user" and not SDP users.


The following illustrates the distinction between the two in events.


4. FQDN vs IP address

Another common scenario where seemingly similar connections are treated differently by Cato (blocked or allowed) is when Fully Qualified Domain Names (FQDN) are used in the Firewall Rules or in custom category/app. Before we delve into the details, let's examine two events, both are sourcing from the same source IP address and destined to the same IP address and port, but with different outcomes—one allowed and the other blocked.


Review the Firewall Rules

In the given example, the connection is either blocked or allowed based on the WAN Firewall rule.

To investigate further, follow these steps:

  • Navigate to the WAN Firewall section within CMA and search for the relevant rules.

  • It becomes evident that rule 1 corresponds to the Monitor (Allow) event. This rule specifically permits connections categorized under "Internal Web Servers". Clicking into the rule reveals that the "Internal Web Servers" is from the Custom Category.

  • In contrast, rule 5 aligns with the Block event. It is designed to block HTTP(s) traffic alongside other services.wanFWrule.jpg

Review the App/Category

Now that we have determined from the Firewall Rule that the connection was allowed based on a match to the "Internal Web Servers" custom category, let's investigate further to understand the condition for this match.

  • Navigate to Assets> Categories > Custom Categories

  • In the list of custom categories, locate and select the "Internal Web Servers" category.

  • Within the category details, it is observed that the member of the "Internal Web Servers" category matches the Fully Qualified Domain Name (FQDN) to

  • This indicates that connection matching to the FQDN will be allowed. (In order for Cato to correctly identify the hostname, we need to see the DNS query/response)

  • Alternatively, any connection that does not correspond to the FQDN will be denied. This is precisely the situation with the blocked connection. The user attempted to access the server using its destination IP address instead of the FQDN. (In this case, since there isn't any DNS query/response, Cato wasn't able to identify the hostname and the rule wasn't matched)
  • In situations where direct IP access occurs without a preceding DNS request, Cato utilizes its DNS cache to attempt matching a domain to the given IP. If the cache does not contain any domains, Cato will be unable to associate it with a hostname or FQDN. As a result, the connection in the aforementioned example will be blocked.
  • Therefore, when an allow firewall rule is configured to match based on the FQDN, it is crucial for the customer to access the server using its domain name to ensure uninterrupted connectivity.
    NOTE: If you are using a private DNS, we need to ensure that the DNS queries/responses go through Cato. For DNS best practices, refer to Best-Practices-for-DNS-and-Your-Cato-Account 

Was this article helpful?

1 out of 1 found this helpful



Please sign in to leave a comment.