Anti-spoofing; network defined by routes with overlapping spaces

[Harald_Hansen]

The network defined by routes feature in anti-spoofing is a very nice addition, though severely flawed.

My example:

We have 10.0.0.0/8 defined in the network and multiple gateways interfacing with their external interfaces toward each other. If there are overlapping routes, anti-spoofing will kill traffic passing the external interface even if there is a more specific route northbound. 

This also appears to happen with VPN traffic, where the gateway kills inbound VPN traffic that is routed towards the peer on an external interface route if there is a wider route matching an internal interface.

If this is intended behaviour, no real world scenario like the ones above have been considered. 

At the moment we have to create anti-spoofing exception groups or disable anti-spoofing all-together. This is probably not what Check Point must have had in mind when designing this behaviour?

Any suggestions? 

[Danny]

Anti-Spoofing is not meant to fix your overlapping routes issue. What you're experiencing is just a subsequent flaw. In these cases I suggest choosing another Anti-Spoofing routine.

[Harald_Hansen]

What an awful answer, you are not contributing to solving this real world problem.

[Danny]

C'mon, my One-liner for Address Spoofing Troubleshooting won a contribution of the year award.

[PhoneBoy]

Let's keep it friendly, folks. 😬

How are the routes in question defined?
Are they static routes defined on the gateway or via dynamic routes?

The primary use case for this is for gateways running dynamic routes.
One limitation is that we don't take into account route metrics when calculating topology.
That's discussed in more detail here: https://community.checkpoint.com/t5/Next-Generation-Firewall/Security-Flaw-in-Dynamic-Anti-Spoofing-... 

Tagging @Meital_Natanson to comment on whether this is operating as designed in your particular case or not.

[Harald_Hansen]

We are moving toward dynamic routing, though you cannot get rid of static routes entirely. Like when you have a large WAN and the telco does not support DR, or like in this case, support it on the other link, that is connected to the other firewall/VS. We are moving slowly, the new connections are with BGP, and the hope was that we could transition just by adding more specific routes. Now we have to keep exclusion groups on all external interfaces or do route calculations that change all the time. Even worse, we don't have a choice when carving out small subnets for VPN tunnels, where there is some overlap in IP address use.

To me it seems like this feature only exists to serve customers that already use DR on all interfaces, at my customers this situation will never occur. Thus this post to clarify the need for an exclusion feature to anti-spoofing on external interfaces based on the more specific routes defined on that interface. This could be optional, so the purist can have their peace.

[Harald_Hansen]

I forgot to answer your questions:

>Are they static routes defined on the gateway or via dynamic routes?

Both, OSPF in the zone connecting perimeter gateways and the various VSX VSes. Static routing southbound towards WAN-links, VPN gateways and internal networks.

>One limitation is that we don't take into account route metrics when calculating topology.

You also do not take smaller masks into account (I'm not sure if route metrics includes that as well).

[Meital_Natanson]

Correct, this is the design.

For any behavior change requirement, I suggest to go with RFE process.

[Harald_Hansen]

I've sent in the RFE to the local CP office yesterday. I'm working for a Check Point partner and will push for improvements through those channels as well.

I'm also a bit curious to how the design process worked on this feature. What was the goals and limitations? Did you take both mid-size and large scale Check Point customers into account when setting the parameters of this feature? 

[Meital_Natanson]

Hi @Harald_Hansen ,

Let's take it offline.

Can you please send me the questions via mail?

meitalna@checkpoint.com

Thanks,

Meital

[Christian_Norda]

I hope this is not Check Point's final stance.. If so, it would be yet another example of Check Point providing a seemingly useful feature, that ultimately (and unfortunately) turns out to be utterly useless in real world scenarios, for all but the most basic environments.

[Bob_Zimmerman]

If I understand your problem correctly, it ultimately comes from what "External" really means: not Internal. An interface configured as External gets the topology of all internal interfaces, ORs them together, then NOTs the result.

Based on my experience with it, Check Point built the "Network defined by routes" URPF option for environments in which routing is used exclusively with exact networks, not summaries like 10/8. While yes, this is the correct way to build an environment in an academic sense, you also raise the valid concern that most real environments are not academically correct.

I actually just ran into a problem with some interior firewalls sitting between two of my datacenters and their WAN links to certain other datacenters. Nice, simple firewall topology. One datacenter-facing interface marked as Internal, one WAN-facing interface marked as External. I tried to flip the datacenter-facing interface on one of the firewalls to have topology defined by routes, and OSPF was lost between that firewall and the WAN-facing interface, which I did not change. The two datacenters were from an acquisition and have a WAN link between them set up to work as a redundant path between those two datacenters and these particular WAN links. The firewall I changed learned all the WAN-side routes from both its WAN interface and its datacenter interface, including the local networks for both the datacenter interface and the WAN interface. The datacenter interface picked up the routes from dynamic routing and added them to its antispoofing topology, and since the WAN interface was External, it had a topology of NOT those networks.

Still looking into how the system behaves if both interfaces are set to use topology defined by routes.

[Harald_Hansen]

You'd probably need to have a dummy interface for external that won't be used. It could work, though there are other internals that depend on northbound traffic passing the external interface. 

To me all insecure networks should be regarded as external, including the WAN. My issues with networks based on routing stems primarily from the old design, merged over to a new VSX/maestro setup. Long term we aim for a more academically correct design, re the message above.

[Bob_Zimmerman]

Traffic can be forwarded between External interfaces, which is what we're doing for the moment. It should also be easy to say both are internal with topology defined by routes, assuming that setting allows the same network to be learned on multiple interfaces.

Antispoofing topology and threat prevention topology were linked in the past, but now are not necessarily. I have several firewalls where the interface facing an Internet link is External in antispoofing, but more trusted in threat prevention terms (the goal is to protect datacenters from malware a user might accidentally bring into the office).

[Wolfgang]

@Harald_Hansen 

I do understand your needs and expectations but what you see is expected behaviour. This is how it works. The networks are defined from your routing entries, regardless routes for more specific subnets.

Maybee there are plans for the future...

tagging @Meital_Natanson and mentioned Security Flaw? in Dynamic Anti-Spoofing (R80.20 and above) . There was a similarly discussion.

Wolfgang

PS. An RFE will be always a good idea.

[Harald_Hansen]

An RFE is in the works, I also have discussions with the local office as well as the Professional Services consultant attached to the project I'm working on. Turning every stone ...