Sepreate gateway in place of ISP Redundancy

[JoeBandura]

Currently, we have deployed a ClusterXL gateway managed by a management server protecting a handful of servers and users through our service provider. Through that service provider we have a /27 that we use to hide NAT various networks and static/hide NAT various servers for both inbound and outbound services. For network redundancy, we will soon be setting up a secondary internet connection through a different provider which will also be providing a /27. I have been looking at using ISP Redundancy to manage the two connections, but this presents some problems with how it's setup and the restrictions on using advanced routing with ISP Redundancy enabled.

With that in mind, I am now considering standing up another firewall that will handle the routing and NAT for the second service provider and just worry about switching our internal default gateway to the other firewall in the event of a failure with the first service provider.

Now, my question is, what is wrong with taking that approach? Is there a problem with duplicating the configuration, NAT rules, subnets, etc. to support another firewall and service provider to protect the same resources? Maybe there is a better way to go about this that I might be missing?

Thanks for any help!

[PhoneBoy]

A diagram of the proposed configuration and traffic flows might help.

[JoeBandura]

A little more background here. I have two sites, one is remote from me (Site A) and the other site is local to me (Site B). Both sites are connected via a private link. Both sites are also currently connected to the internet through the same service provider (ISP-1). Through that service provider, we have 2 connections at each site that are terminated at different POPs within that service provider. Right now, we are only using one of those links at each site Link-1 at Site A and Link-3 at Site B. Our service provider has given us a /26 for use at Site-A and a /27 for use at Site-B. Both ranges are currently routed via static routes. My plan is to configure BGP at both sites with ISP-1 so that our /26 and /27 is usable over both links in each site, and across sites for site resiliency.

For ISP resiliency at Site B, we are getting a new internet connection installed from another ISP (Link-5). Because we don't own our NAT ranges and none of them are /24's, we won't be able to advertise any of the ranges we currently have across ISP's and so we will be getting a new /27 from ISP-2. In the event of an outage at ISP-1, we would switch to ISP-2 and update DNS to use the /27 from ISP-2. I was looking at using ISP Redundancy to manage the NAT changes, but ISP Redundancy can't be used with Advanced Routing/Networking which I will likely be using to enable BGP with ISP-1. My thought was to install a second firewall at Site B to support Link-5 and just update internal routing to point to that firewall in the event of ISP-1 failing.

As I had asked in the OP, what is wrong with taking that approach? Is there a problem with duplicating the configuration, NAT rules, subnets, etc. to support another firewall and service provider to protect the same resources? Maybe there is a better way to go about this that I might be missing?

[PhoneBoy]

Given the various restrictions, your approach seems like it should work.
Obviously, with some extra management overhead to replicate the various configurations.

[JoeBandura]

Right, but is there a better way to do it?

[Bob_Zimmerman]

In case you're not aware, you can push exactly the same policy package to multiple firewalls. Both of the firewalls at site B could run exactly the same policy with a few NAT rules unique to each (using the "Install On" column). You could then use routing on your core router to determine which path to use for outbound traffic. There would be an outage each time you flip between default routes (since each firewall hides clients behind a different IP), but it should be seconds, not minutes.

Inbound traffic is a problem. You can't directly control which IP clients out on the Internet talk to. If you want to be able to accept inbound traffic on both public blocks, you will need to hide external sources behind a unique IP per firewall (or cluster) to maintain symmetry. Since this traffic is pinned to a particular public block, connections wouldn't survive a telco outage, but they should survive administrative failover of your outgoing route.

As an unrelated aside, /29 blocks for the telco links seem awfully large. I wonder why they didn't go with /30 or /31.

[JoeBandura]

We got /29 for a few of the connections. Surprisingly, we requested them and they gave them to us. It made setup of the ClusterXL deployments a bit easier.

[AmirArama]

Hi

i'm not sure that the ISP Redundancy limitation is correct. (can you show me from where you took it?)

from what i found, it's mainly if you are using dynamic routing to inject routes into your GW especially - default route.
in such case the ISP Redundancy static default route will override the dynamic routing default route.
but if you only advertise routes from your GW out, i'm not sure there is an issue - but i'm not ISP-R expert.

You can also consider using our Quantum SD-WAN for spreading your outbound internet traffic over your multiple ISPs in much more intelligent way.

assuming your GWs running full GAIA, you just need to wait for an upcoming JHF that will introduce symmetric packet return, such that s2c return packets will be routed from the same ISP that the original c2s packet was came through.

[JoeBandura]

You may be right, maybe I could make it work. That said, the documentation I have says it's not supported, and I'd hate to put something in place that I won't get support for if issues do come up.

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Quantum_SecurityGateway_Guid...

Important - ISP Redundancy is not supported if Dynamic Routing is configured (Known Limitation PMTR-68991).

[AmirArama]

Yes, this is the PMTR i have read and described above.