Why Multiple Cato Sites Lose Access to Specific Domains With No Firewall Blocks

Overview

Several sites connected through Cato Sockets stop reaching one or two specific external domains at the same time. Everything else on the internet still works. You check the security logs and find nothing blocked.

In most cases the cause is a disabled or modified WAN Firewall / Network Policy. It is not a security rule.

When that policy is turned off, NAT stops being enforced for outbound traffic and the affected sites lose their routing configuration for traffic heading to those domains. The connections then fail at the NAT and routing layer, which is why IPS, Anti-Malware and DNS Protection have nothing to report.

If you are seeing this pattern right now, check the WAN Network Policy audit history before anything else. It is the fastest way to confirm or rule out this cause.

Symptoms

The pattern is specific enough that recognising it gets you most of the way to the answer.

• Users at several branch or site locations cannot reach one or two specific external domains at the same time. General internet access still works normally.

• All sites are affected the same way. It is not limited to one site or one connector.

• Security event logs for IPS, Anti-Malware and DNS Protection show no blocks for the affected domains.

• Internet Firewall logs show only Monitor actions for the affected traffic. No deny rule is being matched.

• The connectivity and event logs show a large, abnormal spike in Socket Bypass events during the same window.

• No tunnel disconnections, PoP changes or link failures are reported for the affected sites in that period.

Each of those signals rules something out.

The Socket Bypass spike is the one that confirms it. A sudden surge means traffic is being routed around the disabled policy rather than dropped.

If your logs do show errors rather than silence, the cause is different. Decrypt or handshake failures point at TLS inspection and certificate pinning instead.

Cause

This happens when the WAN Firewall / Network Policy that governs NAT and routing for outbound traffic is disabled or modified. When that policy is turned off:

1. NAT rules for outbound traffic stop being enforced.

2. Affected sites lose their routing configuration for internet-bound traffic to the impacted domains.

3. Traffic destined for those domains can no longer be properly routed or NATed, and connections fail even though no security rule is blocking them.

The failure starts at the NAT and routing layer rather than at a firewall rule. That is why it gets mistaken for a security block or an upstream provider outage until someone checks the policy audit log.

In the incident this article is based on, the disabling change was traced to a single administrative action on the WAN Network Policy a few minutes before the outage started. The volume of Socket Bypass events during the window confirmed that traffic was being redirected around the disabled policy rather than blocked.

Resolution

Restoring access quickly

If the affected domains are business critical and you cannot re-enable the policy straight away, create a temporary Socket Bypass rule for the specific destination domains and apply it to the affected sites. This routes traffic around the disabled policy and restores access while you investigate the configuration.

Keep the rule scoped to the named destinations. A broad bypass rule leaves an unmanaged path around your policy layer. For an example of bypass used deliberately rather than as an emergency measure, see configuring a UDP direct breakout rule for Parsec traffic.

The permanent fix

Step 1. Find the change. Use the audit and change log to identify the WAN Firewall / Network Policy change that disabled the policy.

Step 2. Re-enable the WAN Network Policy.

Step 3. Verify NAT. Confirm that NAT rules are working correctly for outbound traffic.

Step 4. Test connectivity. Test access to the affected domains from all impacted sites.

Step 5. Remove the emergency bypass. Once the policy is confirmed working, check whether the Socket Bypass rules are still needed. Remove them if they are redundant, so you are not left with unmanaged bypass paths.

How to Confirm It Is Fixed

Do not close the incident until all of these are true.

• The WAN Network Policy shows as enabled in the configuration.

• NAT rules are confirmed working for outbound traffic.

• The affected domains are reachable from every impacted site, not just the one you tested from.

• Socket Bypass event volume has dropped back to its normal baseline.

• Any temporary bypass rules created during the incident have been removed, or there is a documented reason for keeping them.

Step 5 is the one teams skip. A bypass rule left behind after the real fix sits there as a quiet route around the policy layer, and it usually does not resurface until the next audit or the next incident.

Prevention

Policy and process

• Require an approval step before any critical policy can be disabled or materially changed. This covers WAN Network, Internet Firewall and Socket Bypass policies.

• Set a defined change window for production policy modifications, and document the rollback plan before making the change.

Technical controls

• Configure real-time alerts for changes to critical policies, particularly any change that disables a WAN Network or Internet Firewall policy.

• Restrict the ability to disable whole policies to senior administrators, and review wider admin permissions periodically.

• Keep versioned snapshots of working policy configurations so you can roll back quickly.

• Alert on abnormal spikes in Socket Bypass events. A sudden surge is an indicator of an upstream policy or routing problem in its own right.

• Validate policy changes in a staging or test environment before applying them in production. This matters most for WAN Network Policy changes that affect NAT.

Documentation and training

• Keep a runbook covering the relationship between the WAN Network Policy and NAT behaviour, with a troubleshooting checklist for similar connectivity issues.

• Document the emergency bypass procedure so on-call staff can restore access while a permanent fix is worked out.

• Go through this type of incident with your administrators so the impact of disabling policy-level settings in production is understood.

What This Incident Really Shows

The problem here was not a technical limitation. It was change visibility.

One administrative action disabled a policy, and the outage that followed looked enough like a security block or a provider issue to send troubleshooting down the wrong path for a while.

Two controls shorten that more than anything else: alerting on critical policy state changes, and alerting on Socket Bypass volume anomalies. Between them, a multi-site outage of unclear origin becomes a named change with a timestamp on it.

If you want help tightening change control, alerting or incident runbooks across your Cato sites, talk to NetNXT.

FAQs

1) Why can my Cato sites not reach a specific domain when general internet access still works?

This is usually a disabled or modified WAN Firewall / Network Policy. Without it, NAT is not enforced and the routing configuration for that destination is lost, so connections fail at the routing layer instead of being blocked by a rule.

2) Why do the Cato security logs show no blocks when traffic is clearly failing?

Because nothing is being blocked. IPS, Anti-Malware and DNS Protection will show nothing, and the Internet Firewall will show only Monitor actions, since no deny rule is being matched.

3) What does a sudden spike in Cato Socket Bypass events mean?

It means traffic is being redirected around a policy rather than dropped. A sudden surge is a reliable sign of an upstream policy or routing problem and is worth alerting on.

4) How do I restore access quickly while I investigate?

Create a temporary Socket Bypass rule for the affected domains and apply it to the impacted sites. Remove it once the WAN Network Policy is re-enabled and verified.

5) How do I confirm that a WAN Network Policy change caused the outage?

Check the WAN Network Policy audit history for a disabling action shortly before the outage began, then correlate it with the Socket Bypass event spike over the same period.