Topology defined by routes limitation?

[Christoph]

Hello,

R80.40 environment.

I have one network 10.10.48.0/20 statically routed to a DMZ. A (more) specific subnet (10.10.60.0/24) from this network is routed to the external Interface.

Most of the other interfaces topology are defined by an object group.

Return packages from to the external interface are dropped by anti spoofing.

Is this an expected behavior, like no splitting of the /20 takes place internally?

Overall I wonder how topology information ist merged and processed when one has multiple route information sources, like defined by routes, objects and interfaces.

Anyway fix for the above was a group with exclusion, but for me it was a bit of an unexpected behavior, that's why I'm asking.

Cheers

Christoph

[PhoneBoy]

It’s possible this is a limitation similar to the fact we don’t take into account route priorities. 

[Tobias_Moritz · Accepted solution]

PhoneBoy is right, unfortunately.

There was a discussion about this topic about a year ago (initiated by me):

https://community.checkpoint.com/t5/Security-Gateways/Security-Flaw-in-Dynamic-Anti-Spoofing-R80-20-...

Unfortunatly, @Meital_Natanson told us, they do not want to fix that and call it expected behavior.

Bad decision from my point of view, there is even a "Best current practice" RFC#3704 from 2004 for that.

Like another Checkmates member said in the thread linked above:

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

[Christoph]

Thank you both of you. I checked your thread. From my (maybe naive) point of view, if there is an option in the UI, my general expectation is, it should also cover edge cases, as long as I can configure them, like in this case click a button. Other than that there should be a big warning sign, that this only works in certain environments.

Same with the new custom vpn topologies, that do some weird network calculations.