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]

What was the source version/build that you upgraded from and are you in contact with TAC?