Intermittent Packet Loss and DNS Resolution Failure after R82 Upgrade

[b2tik]

1. BACKGROUND & ENVIRONMENT

Device Model: Quantum Spark 1800 Appliance

Firmware Version: R82.00.10 (Build 998002242)

Management: Locally managed

Network Topology:

Internal network (Client/AD-DNS): 172.22.1.0/24

Check Point LAN12 interface: 192.168.10.1/29

Upstream gateway (BelVPL): 192.168.10.2 (connected to LAN12)

Remote DNS server (SMDO): 10.10.9.8 (reachable via BelVPL gateway)

2. PROBLEM DESCRIPTION (SYMPTOM)

Issue Type: Intermittent packet loss and DNS query failure

First Observed: Immediately after upgrading firmware to R82.00.10 (998002242)

Current Impact: Critical — Internal DNS resolution for the SMDO service is unstable. This affects all internal clients relying on the AD-DNS server (172.22.1.100) to resolve names via the remote DNS server (10.10.9.8).

Detailed Description:

Packet Loss: Pings from internal clients to the remote DNS server (10.10.9.8) show significant packet loss (approx. 50%) and high latency (up to 1905ms). Pings to the immediate next-hop gateway (192.168.10.2) are stable (1-2ms).
DNS Failure: DNS queries (nslookup) to the remote server (10.10.9.8) consistently fail with the error Query refused.
Logs: The firewall logs show Action="drop" with message_info="Address spoofing" for traffic from the internal AD-DNS server (172.22.1.100) to the remote DNS server (10.10.9.8).
3. ACTIONS TAKEN & TROUBLESHOOTING DONE

Verified physical layer: Cables and link to 192.168.10.2 are operational (no errors on interface).

Temporarily disabled global Anti-Spoofing (fw ctl set int fw_antispoofing_enabled 0). This stopped the Address spoofing drops in the logs, but the packet loss and Query refused error persisted.

Disabled all non-essential blades (SSL Inspection, SD-WAN, Fast Accel) to rule out performance impact from new R82 features.

Confirmed that NAT is correctly masquerading traffic from 172.22.1.0/24 to 10.10.9.8 behind the LAN12 interface IP (192.168.10.1).

Performed a packet capture (if available) and traceroute, which shows traffic reaching the destination but with significant loss and refusal.

This all happened immediately after updating to the new firmware version.

[Chris_Atkinson]

With reference to sk184492 what was the source version/build that you upgraded from and are you in contact with TAC?

[b2tik]

 

Upgrade path:

Previous version: R81.10.17 (Build 996004721)

Target version: R82.00.10 (Build 998002242)
The upgrade was performed directly via the web interface.

Contact with TAC:
The case was opened through the Check Point Support Center (help.checkpoint.com)

[Lesley]

Did you find the reason for the anti-spoofing drops? This means the traffic is reaching an interface that it should not reach. Most of the time it is return traffic. If this is dropped it can look like packet loss. The question is what is send the traffic back on the incorrect interface? Or is it really a false positive (never seen that tbh) 

[b2tik]

Yes, we have identified the reason for the anti‑spoofing drops.

Root cause
The traffic from 172.22.1.100 (our AD/DNS server) reaches the firewall on interface LAN2.100 (IP 10.100.100.254/24). However, the routing table shows that the network 172.22.1.0/24 is directly connected to a different interface – LAN3.172. The anti‑spoofing mechanism compares the ingress interface with the one expected for the source network and drops the packets because they do not match.

What we have already tried (without success):

Disabled global anti‑spoofing via the WebUI (Device → Advanced Settings → uncheck "Enable global anti‑spoofing").

Disabled anti‑spoofing via CLI: set antispoofing advanced-settings global-activation false.

Manually disabled the kernel‑level check: fw ctl set int fw_antispoofing_enabled 0 (and also performed fw kill to restart the firewall).

Despite all these measures, the drops (Address spoofing) persist in the logs. It appears that either the settings are not taking effect for accelerated traffic (SecureXL) or there is a persistent kernel‑level cache.

What we need from you
We would like your assistance to configure a permanent and safe exception for this specific source (172.22.1.100) on the ingress interface LAN2.100, without compromising global anti‑spoofing protection. For example:

Adjusting the interface topology to include 172.22.1.100/32 as an allowed source behind LAN2.100, or

Creating a proper Don't check packets from rule (if possible for internal interfaces in this firmware version), or

Any other recommended approach that does not involve altering routing for the whole /24 subnet.