- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hello Mates,
We are getting this issue in which the tracker is showing 2 logs for the same traffic (same source and destination port numbers) one is getting encrypted (and accepted) and with the same time stamp another one which is getting dropped at the external interface with reason of address-spoofing. Below are the details:
The source is 10.1.4.0/24 and is directly connected to CP firewall. The source is getting natted to IP 194.168.1.153 (subnet 194.168.1.x is not configured on any of the interface of this firewall. The VPN is configured with interoperable object and the tunnel are up. When initiating the traffic with source 10.1.4.233, in the tracker we can see the source is getting natted to 194.168.1.153 and also the traffic is getting encrypted. Just after this log ( with the same timestamp) another drop log is there with source 10.1.4.233, same source port and destination and getting reason is address-spoofing on eth2.530(external interface). On putting tcpdump on eth2.530 we are not getting any hit.
On "fw monitor -p all", I can see the traffic (Syn) is passing through the firewall after getting translated, also receiving the reply back (Syn/Ack) to 194.168.1.153 but only i (Pre-inbound) after that no IoO. We have done manual hide nat configuration.
Please let me know if any further info required. Thanks in advance.
The second log is an anti-spoofing drop based on the destination IP address which you have not revealed in your post. What is the destination IP address and is it defined in the topology of an internal interface of your firewall? It should not be. You probably have the entire RFC1918 range defined as your internal firewall topology, yet the destination IP address for this VPN-bound packet is part of RFC1918 as well. If you'd rather not adjust the firewall's internal topology (which is always a bit nerve-racking as you may suddenly run afoul of antispoofing in ways you aren't expecting), on the topology screen of the External eth2.530 interface populate the "Don't check packets from" option to set an antispoofing exception for this specific VPN traffic.
The second log is an anti-spoofing drop based on the destination IP address which you have not revealed in your post. What is the destination IP address and is it defined in the topology of an internal interface of your firewall? It should not be. You probably have the entire RFC1918 range defined as your internal firewall topology, yet the destination IP address for this VPN-bound packet is part of RFC1918 as well. If you'd rather not adjust the firewall's internal topology (which is always a bit nerve-racking as you may suddenly run afoul of antispoofing in ways you aren't expecting), on the topology screen of the External eth2.530 interface populate the "Don't check packets from" option to set an antispoofing exception for this specific VPN traffic.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 12 | |
| 10 | |
| 9 | |
| 8 | |
| 6 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY