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
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
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
The firewall builds a permanent ssh connection to Panorma. if the connection is disrupted, it will try periodically to reconnect, panorama backchannels everything over that connection.
Your scenario should be quite rare where the active member fails without failing over. You could build in some contingencies by adding path monitoring (additional reasons for the primary to fail, and the secondary to take over)
This problem can also be fixed by non-IT staff, by having a local user pull the plug on the chassis: make sure preempt is enabled so the 'primary' is always the active one whenever it is capable, and clearly mark the chassis with a sticker
if you really need a failsafe, you'd probably want some type of 'call home' device on-prem that has 4g capability and is only allowed to make an outbound VPN to your primary site, one the primry internet link goes down
Hi @Reaper,
I finally configured the Firewalls and Panorama following your suggestions, and it seems it works fine.
I got continuously disconnections between firewalls and Panorama like descibed into this KB:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boD5CAI
Do you have any suggestions?
In case I can leave only the private IP of Panorama configured on the firewall and in case the VPN will go down I will change manually the IP of Panorama to the Public IP.
Thanks.
Jacopo
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