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)