- Products
- Learn
- Local User Groups
- Partners
- More
The Great Exposure Reset
24 February 2026 @ 5pm CET / 11am EST
CheckMates Fest 2026
Watch Now!AI Security Masters
Hacking with AI: The Dark Side of Innovation
CheckMates Go:
CheckMates Fest
H all,
I've a general question about a best practise for noobs 🙂
Some clients in our network try to communicate with RFC1918/private IP addresses, which subnets are not existing in our network.
Therefore, the traffic takes the default route to our perimeter gateway (CP 9000 Appliance) which forwards it to the ISP line.
I think it's not a big problem, but I don't like to see traffic with private IP addresses as destination on our WAN line.
What are your suggestions to block or reject the traffic before it enters the ISP line?
Is blackhole routing a good idea? I'm not sure if the priority of smaller routes for a subnet within the blackhole route is higher. I'm afraid to block any traffic by adding a blackhole route like 10.0.0.0/8.
I would look into why the rules are allowing the traffic out. If a private destination isn't in your network or at the other end of a VPN, you probably shouldn't have rules allowing traffic to it.
Routing should not be used for access control. Down that path lies incredible and lasting pain.
I totally second what Bob said. If you think about it logically, say even if routes are 100% right, say if rule said any any block, then nothing would work, except web ui to 443 (ONLY that port) and ssh, thats it.
Also for me, I agree with Bob and The_Rock, if there is traffic for RDC1918 private IP addressses that doesn't exist in your network the best solution is to create a rule to block this traffic (put the rule in the right position, before the rule that permit traffic to Internet.
100%, thats what I would do as well.
There are different aspects to this question. The policy should indeed be correctly articulated.
However in a controlled and segmented network, a blackhole route for private ranges with their largest subnet mask can eliminate back and forth traffic which would be accepted by the policy but would cause unnecessary sessions and load on the NIC's.
Let's say you route from your core the default to the FW and on the FW 10.0.0.0/8 to the core instead of the discrete networks you use.
Now an application with misconfigured, hardcoded or incorrect values would talk not to 10.1.1.1 but to 10.2.1.1 which doesn't exist. If somehow this flow would be permitted in the rules, you would have a loop until the TTL stops the party. Multiply this by hundreds or thousands depending on the architecture and you use X% of your capacity in useless traffic.
Whenever we can, we use those blackhole routes and ensure the supernets or segments are routed towards the core or reside on direct VLAN for a more intentional, predictable routing.
On top of a sensible security policy, of course.
Or do it different: no default route to internet breakouts. 😉
Overly broad routes like 10/8 are approximations, same as approximating pi as 3 (astrophysicists even tend to approximate pi as 1!). Approximations can be useful, but they're not correct. Correct routing allows you to have correct antispoofing, which certain industry standards like PCI-DSS require.
To be sure, it takes a long time and a lot of work to get to the point of correct routing, but it gets rid of whole categories of issue.
I might have been unclear. My point is that in a 10/8 network, I would send 10/8 to Null/Blackhole and ensure that only production segments are known with their relevant CIDR via any form of routing.
If this is incorrect, I'm always happy to learn.
EDIT: Yeah, I get your point about anti-spoofing - it's just that it's not always applicable depending on some operational realities.
The best option would be to stop sending not needed traffic from the source devices. If that specific traffic is not leaving end devices, you can save some utilization and bandwidth for important traffic. It will also help firewall to not handle such a traffic, including all infrastructure devices in the path (switches, routers, ...).
Identify problematic end devices, contact responsible guys for identified end devices to stop traffic which is not needed (blackroute, stop services, correct routing).
Thank you all for your helpful responses.
I like @Alex- post because it considers several aspects.
I started to review the firewall rules as well as our routing.
What should I say, it's a mess.
The previous responsible person for our firewall used often "Any" for destinations or sources. That's why non-existing RFC1918 subnets are routed to the WAN line.
The routing in our network contains routes for 10.0.0.0/8, 192.168.0.0/16 and 172.16.0.0/12, which forward non-existing RFC1918 destinations to our perimeter firewall from all our locations.
I started to identified all our internal networks to create a network object for internal resources. Also, I created a object "Internet" which is a negated version of RFC1918. I plan to replace all rules with "Any" in destination or source with the matching objects.
And we will create more specific routes based on our internal subnets to eleminate the traffic for non-existing networks.
That will hopefully eleminate the private IPs on our Internet line.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 22 | |
| 22 | |
| 13 | |
| 9 | |
| 9 | |
| 8 | |
| 8 | |
| 8 | |
| 7 | |
| 7 |
Thu 12 Feb 2026 @ 05:00 PM (CET)
AI Security Masters Session 3: AI-Generated Malware - From Experimentation to Operational RealityFri 13 Feb 2026 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 43: Terugblik op de Check Point Sales Kick Off 2026Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesThu 12 Feb 2026 @ 05:00 PM (CET)
AI Security Masters Session 3: AI-Generated Malware - From Experimentation to Operational RealityFri 13 Feb 2026 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 43: Terugblik op de Check Point Sales Kick Off 2026Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY