To test this feature, visit your live site.

Multiple firewalls around the world

Dear Gurus,

in the coming few months we will migrate a customer from Check Point to PAN (finally 😀). Customer will implement a cluster for each branch offices.

This customer has a lot of branch offices around the world. Actual Check Point are managed centrally by firewall public IP.

We will use Panorama to manage all firewall, but we are not sure how we can be sure to always reach the MGMT Interface. I mean, we want to configure a public IP also for the MGMT Interface in order to be able to commit and change config if the VPN is down. I found the following scenarios but I want a feedback regarding what is the best:

1) MGMT interfaces configured with public IP and Permitted IP addresses limited to HQ customer public networks.

2) MGMT interfaces natted itself by the firewall on two specific public IP (one for each members) and filtered by a security policy.

3) MGMT configured into the LAN and configure public IP of Panorama. The traffic will be Natted by the firewall to reach Panorama public IP. Will the commit works successfully? the Panorama cannot initiate traffic to MGMT IP.

Any other idea?

Thanks in advance.

Jacopo

7 comments

Comments (7)

jacopo.vigano

Nov 16, 2020

Hi @Reaper,

Ok Understood.

But in case of commit, is Panorama that initiate the connection to the firewall?

In this scenario the only way to not reach both firewalls, is freeze of the active member without failover.

We need to avoid any possibility to reach both members beacuse into the majority of branch offices there are no IT people.

Thanks.

Jacopo

Reaper

Dec 31, 2020

Replying to

Hi @jacopo.vigano that's a good point... you could block the public IP on the central site as long as the private link works fine, or you could indeed only use the private IP until there is a failure and then put in the public IP. You could also work with an FQDN for which you could change the A record, or set up a discard/blackhole route, or a PBF policy that fails 'open' if the tunnel goes down.

Manually switching the IP, however, is probably the easiest approach

jacopo.vigano

Jan 05, 2021

Replying to

@Reaper I think Manually switching is the best option.

Actually I have the firewalls connected on the private IP inside the VPN and I see the firewalls correctly connected but Panorama cannot receive the logs because the firewalls keep the public IP (I dropped the traffic on the firewall that NAT Panorama) as priority.

Panorama is configured as Panorama mode and the Primary IP of Panorama into the firewalls is the Private.

That's strange, it's seems there are different behaviours between Panorama and Log Collector.

Do you have any suggestions?

Thanks.

Jacopo

Reaper

Jan 05, 2021

Replying to

What IP is set in panorama > setup > Interfaces ? Is there a public IP there? If so, try removing it. Then commit to panorama and then publish out to devices making sure you select the log collectors as destination as well

Reaper

Nov 16, 2020

Hi Jacopo

The firewall will always connect to panorama, panorama will never connect to the firewall.

you can actually set 2 IP addresses for Panorama on a firewall, so you could set the internal (RFC1918) Panorama IP as the Primary Panorama, and it's public IP (NATed on the firewall in front of Panorama) as the second

The firewall will prefer the primary IP, which should go through your VPN tunnel, if the VPN fails the firewall would fall back to the public IP. (source NAT on the office firewall can use the same IP for both firewalls, they connect to panorama and identify themselves by their serial number, source IP can be the same)

As a third, final resort, you could set an inbound NAT policy sourced from your central public IP, destination your local external IP, destination ports 10443, 10022, 20443 and 20022 (for example) and destination NAT those to your 2 firewalls ports 443 and 22 for management purposes. This connection would only serve to allow administrators direct access in case Panorama connectivity is completely down.

I don't recommend setting a management interface on a public IP, or a mgmt profile on an external interface: leverage NAT + security Policies instead

Forum: Forum