Create a Post
Showing results for 
Search instead for 
Did you mean: 

Security Flaw? in Dynamic Anti-Spoofing (R80.20 and above)

Hello community,

I think some of you did really appreciate the new Anti-Spoofing feature in R80.20 which finally allowed us to define Anti-Spoofing by routes, which makes admins live easier as only routing has to be configured correctly (and it allows some dynamic routing scenrios to work without scripting)

My team was also happy about that and tests showed that is was working. Well, at least we thought so.

While this feature is not blocking traffic it should allow, it allows traffic which it shouldn't.

Maybe we were expecting too much or did not understand the documentation correctly, so please tell me, what you think.

Please take a look at this very simple static lab setup (I guess it is also a pretty common one in small real life setups):


What do you think what happens, when you send a spoofed IP packet which has a source address of from intranet to firewall?

We expected it would be dropped by Anti-Spoofing, because routing table on gateway says this address would be routed to DMZ A and not to Intranet. There are two reasons for this routing decision (one would be enough):

  • more specific route for this IP address on DMZ A instead of Intranet
  • directly connected instead of static route

There is only one scenario, where gateway would send traffic to this IP address over the intranet heading interface from the routing point of view: If gateways interface to DMZ A is down. But in our test case, all interfaces are up and working.

So routing clearly says, this IP address belongs to DMZ A and therefor IP packets which such a source address should never come from Intranet.

Unfortunately, this is not how Checkpoint implementation is working currently. This spoofed traffic is accepted.

It looks like Checkpoint implementation is just grabbing all routing table entries for the interfaces and not takes care which routes have higher priority if conflicts exists and how routing decision is really done.

So now the question to the community and Checkpoint staff: It this the expected behaivior?

Thank you for any ideas!


All tests were done with R80.30 JHFA T191 on Gaia 2.6.

5 Replies

Hi Tobias,

What you described is the expected behavior.

We don't consider routes priorities.



0 Kudos

Thank you very much for confirming this as expected behavior from Check Point side!

May I ask, if there a plans to reconsider this decision?

Maybe I'm wrong with that assumption, but I think many customers will think that "Anti-Spoofing by routes" means it follows the routing logic. And having overlapping route advertisments (or even static routes like in my simple example above) in enterprise networks is a quite common scenario out there...

0 Kudos



The are currently no plans to change it.

Correct me if I'm wrong, but as long as the route exists (even with lower priority), you can't consider it as spoofed traffic.

Otherwise, the routes should be changed.

Customers are using this feature when their networks are updated frequently or when using dynamic routing. So anti spoofing will be applied according to the routes defined on the GW and they won't need to update the networks in SmartConsole on every route change.

0 Kudos

I also see the improvement with having this feature to finally allow dynamic layer 3 topologies. Really appriciate it.


Almost every larger enterprise network I've seen so far in my career was using overlapping route advertisments or static routes to either make network admins life easier or to provide redundancy in having fallback routes.

I guess every network admin knows how routing works and that the current layer 3 network topology is defined by routing decisions on every hop which follow known rules. That said, traffic coming from directions where the current network topology would not route it back the way it was coming from has to be treated as spoofed ("URPF strict" in Cisco terminology, there is even a RFC for that: RFC#3704).

When looking at my little drawing in the first post here, there is only one theoretical case, where traffic with source can come from Intranet - from the routing perspective. And this case is when the interface to DMZ A is link down. In that case, we have other problems than thinking about spoofed traffic. So I guess it is valid that a firewall admin will see this as valid and secure configuration - from the routing perspective.

What I want to say: If you advertise a feature called "Anti-Spoofing defined by routes", I guess most customers will think Anti-Spoofing is following the routing logic of the gateway OS. And because the real implementation is not overblocking, almost nobody will see that it is not working this way. That's why I used a headline with "Security flaw?" in it.


While I agree this logic should apply to route priorities; if we lose a higher priority route for a network we want accept traffic via the the next priority route that gets installed in the FIB, which suggests the process is pulling routes from the RIB rather than FIB. This is OK, and I also appreciate having this well needed feature.

But a more specific route always takes precedence over a less specific route regardless of priority weight or admin distance, and unless asymmetric by design we should not expect to receive traffic on one interface where a more specific route exists via another. Just as this logic applies to the default route, it should also apply to less specific routes as in the OP's lab.

I would agree the current implementation presents a security flaw especially when less trusted networks appear on private addresses where route summarisation is in use.

It would be great if Check Point made plans to follow the RFC, rather than a loose interpretation of it 🙂