Checkpoint Advanced OSPF Capability

[Matt_Hubach]

Hello, we would like to move some features we are running today from a Cisco router to the Checkpoint firewall. I have several questions about this. Currently we are redistributing our Checkpoint default route into our OSPF domain which works fine. However, we are preparing to implement a second Internet ISP connection and want to redistribute the Checkpoint default route based on conditions. In the Cisco world, we do this using IP SLA^s. We setup an IP SLA to monitor upstream IP^s addresses, for example 8.8.8.8. If the IP SLA cannot ping 8.8.8.8 the default route will not be redistributed. 

Does Checkpoint have the ability to redistribute its default route based on this condition? 

Also, can I create permanent static routes in Checkpoint? I would want to redistribute a permanent static route into our OSPF domain so our IP SLA cannot reach 8.8.8.8 via the second Internet ISP.

[PhoneBoy]

As far as I know, there isn't a way to redistribute a route based on reachability of a specific IP.

You can, of course, create static routes in Gaia, and you can use route filters to determine which routes do not go to a specific domain. 

Refer to: How to configure route redistribution and inbound route filters in Gaia Portal 

[Vladimir]

While IP SLA is not available, you can still monitor the state of the upstream device using ping and disable default route redistribution if it fails.

Below is the example of similar settings for BGP on Gaia, but I recall doing the same for OSPF:

[PhoneBoy]

R&D reminded me of this yesterday.

[Vladimir]

It would actually be nice if CP can implement the option similar to IP SLA.

The ping gets us to recognize the next hop's availability, but if the problem is upstream of it, it is difficult to manipulate route distribution based on route integrity.

[PhoneBoy]

Additional capabilities in this area are planned.

If you have an immediate need, I recommend engaging with your Check Point SE.

[Matt_Hubach]

Yes, a function similar to Cisco IP SLA's where we could monitor further upstream would be nice. Thx Dameon.

Also, either of you know the answer to this?

R1--->CPfw--->R2

I have a single default route on R1, using an IP SLA. If the track is down, R1 will remove the default route. I want to redistribute R1's default route into my OSPF domain. Will the checkpoint firewall OSPF process pass R1's default route into R2's OSPF process?

[Vladimir]

I am a bit rusty, but this is what I recall:

If you have a static default route on CPfw, it will take precedence over the one received from upstream router via OSPF.

Not having static 0.0.0.0 on CPfw is a bad idea.

If you have a static 0.0.0.0/0 on CPfw, you can forego "redistribute connected" and allow OSPF propagation into the zone, but then you'll have to define static routes to the networks behind CPfw on the downstream router.

Otherwise, once 0.0.0.0/0 stops propagating due to the loss of connectivity by the upstream router, the traffic will not be aware of the destination.

Check if there is a possibility to select particular connected routes for redistribution. I recall that option being available in IPSO, but am not sure about Gaia. 

Do take these statements with the grain of salt: It's been a while since I've done BGP and OSPF work with Check Point.

Regards,

Vladimir

[Matt_Hubach]

I'll let you know after tomorrow night. I do not want a static route on our Checkpoint firewall (border FW). We have dual providers terminating their service in two diff physical locations. If locationA internet is down, I want the other Internet routers default route to propagate through the OSPF domain.

R1---CPfw1---R2

                             \

                             /  OSPF Network

R3---CPfw2---R4

R1 (ISP1) and R3 (ISP3) will be redistributing their default routes. I just want to make sure the CPfw's pass the default-information originate command through. ????

[Vladimir]

Well,

You can run IPSLA to outside world on your internal routers and keep the route 0 cost reversed on each side. This way, hosts on the inside of Check Point will be able to get out through any available ISP.

Networks located on DMZ(s) could keep propagating normally.

Inbound traffic to your hosts (i.e. mail, web, etc..) may be a bit trickier, since you’ll have to create conditional NAT rules that will take under consideration where the traffic destined to those is coming from.

Another issue will be the antispoofing for hosts in DMZ: Under normal circumstances, fw is aware of the interface leading to the Internet.

During failover, depending on topology, route 0 may end-up behind internal interface.

If you have class C public addresses, you can run cross-site BGP on the outside of your firewalls to prevent the scenario described above.

Vladimir Yakovlev

973.558.2738

<mailto:vlad@eversecgroup.com> vlad@eversecgroup.com

[Marco_Valenti]

Hi Vlad sorry to bump up an older post can you show me where you can add that control for ospf? was searching in advanced routing settings without luck.

Thanks

[Vladimir]

Marco,

Can you restate the question with some specifics?

I'ts been a while since I've looked at this thread and I'll have to get my bearings again.

[Marco_Valenti]

was looking for a way to monitor ospf neighborship state with gaia os so it look like that for bgp you can monitor your peer state with the screenshot that you took but can be possible too in ospf?

[Vladimir]

Marco,

I am presently out of the country and do not have an access to my lab.

Please ping me after 16th of October and I'll look into it.

There were also some changes in R80++ versions that should allow for SNMP OSPF neighbor state change monitoring, but I am not sure if you can use that feature, nor have I seen MIBs for that.

Dameon Welch-Abernathy‌, you have mention a while ago that there were plans to address a detection of upstream connectivity changes other than pinging adjacent devices. Please advise if anything has materialized.

Regards,

Vladimir 

[Marco_Valenti]

Thanks Vladimir no worries catch you soon

[PhoneBoy]

With R80.20, BFD (Bidirectional Forwarding Detection) is an option.

[Vladimir]

If it's not too much trouble, can you drop a link here to the description of that feature?

Thanks!

[PhoneBoy]

There is little mention of BFD support in the R80.20 except in the release notes.

There's a hotfix on R80.10 that adds it: Advanced Routing and Clustering Enhancements Hotfix for R80.10 

The documentation that comes with that hotfix has a little more about it: R80.10 Advanced Routing Accumulated Hotfix for use with JHF Take 91

[Matt_Hubach]

In case anyone runs across this down the road. We finally got this working. Nothing magic, quite simple though. We have 2 ISP's terminating in 2 separate data centers. Our objective was to redistribute the default routes into our OSPF domain from those two Cisco Internet routers. Those default routes are dictated by an IPSLA. If the IPSLA is down, the default route is removed. That all works just fine. The issue was this. The default routes were be redistributed throughout our OSPF domain, but the Checkpoint firewalls never learned them. After hours and hours of CP support we couldn't figure it out. I did not want static default routes on the firewalls. The key to getting this to work was to redistribute the default routes from Cisco into OSPF as type-1. Type-2, checkpoint does not like. I never did get an answer as to why...and I am leaving it at that for now.

[Vladimir]

Matt,

Can you tell me how you've dealt with the anti-spoofing now that you have 0 routes on multiple interfaces?

[Matt_Hubach]

Vladimir, all of our interfaces on our firewalls are being redistributed into OSPF. We aren't running into any anti-spoofing problems. This didn't change the direction of any routes, just how we route. Instead of a static default route, the CP's are learning their default route from our Internet router. Does that answer your question? 

[Vladimir]

Sorry, it is not clear to me how this could be possible.

If your topology looks like this:

Internet---R1---(External)-CPfw1-(Internal)---R2----R4---(Internal)-CPfw2-(External)---R3---Internet

And the idea was to get route 0 dynamically from either site, should the primary fails, than the secondary route0 will be behind internal interface of the firewall and thus the antispoofing will not work.

The only exceptions that I can think of is if your site-to-site routing between external interfaces of the firewalls.

But according to your diagram:

R1---CPfw1---R2

                             \

                             /  OSPF Network

R3---CPfw2---R4

Do the CPfw1---R2 and CPfw2---R4 signify secondary external interfaces of the firewalls?

Thank you,

Vladimir

[Matt_Hubach]

Vladimir, everything internal is in the same OSPF domain, including the "internal interfaces" of the internet routers. There is no site to site via the Internet.

Our network is now basically divided in half. The "left" side routes out internet router R1 and the "right" side  routes out internet router R3. So any site closer to R1 (OSPF cost wise) routes out the "left" and sites closer to R3 route out the "right" side.

When R1 fails, the "left" side will begin learning the only other default route in our network from R3. Assuming that ISP from R1 is down, incoming traffic is down (no BGP peering with ISP's, for now), but the outbound will route out R3 for our entire  campus. Everything heading towards CpFw2 will be from a defined internal networks. Our Internet Fw's are in the same cluster so we have a single rule base we manage. No packets are traversing the CpFw1 external interface if  R1 is  not distributing its default route. There are no internal networks off R1 or R3.

[Vladimir]

OK. thanks for taking time to describe your deployment scenario.

I see that so long as you do not have anything else connected to your firewalls, this will work.

My doubts were caused by the mistaken assumption that you will have a DMZ(s) defined on each firewall.

If that would have been the case, and the fw1, in your example, would learn alternate route 0 from R2, the topology of fw1 would change. Same goes for fw2.

In the absence of DMZs, the only route of significance is 0 and you'll be completely ignoring the firewall that does not receive it from adjacent ISP router.