About S.Cantwell

PAN-OS does not have a built-in way to make a management FQDN automatically move between Active/Passive HA peers. To ensure Kerberos SSO continues working, the shared management FQDN must always resolve to the active firewall’s management IP, and this must be handled outside the firewall. Supported ways to do this DNS-based solution (most common) Create one FQDN (e.g. fw-admin.company.com ) Point it to the active firewall’s management IP Use a low DNS TTL (30–60 seconds) Update DNS manually or with an external script that detects HA failover Reverse proxy / load balancer Place a proxy in front of both management interfaces The proxy has the stable FQDN and forwards traffic only to the active firewall No DNS changes needed during failover Cloud floating IP (cloud-only) Some cloud platforms can move a virtual IP between HA peers This is handled by the cloud, not PAN-OS Important points PAN-OS does not support a floating/virtual management IP on physical firewalls You must not create multiple SPNs Administrators must always access the firewall using the shared FQDN The solution relies on DNS or infrastructure, not firewall configuration Bottom line: Use a single management FQDN and a single SPN, and control where that FQDN points using DNS or an external proxy.   ... View more

For Kerberos SSO access to the PAN-OS admin UI in an Active/Passive HA pair, you do not configure a second SPN on the firewall. The correct and supported design is to use one shared management FQDN and one Kerberos SPN, used by both HA peers. How Kerberos works in this scenario Kerberos authentication is based on the service hostname (FQDN), not on the individual firewall device. The browser requests a Kerberos ticket for: HTTP/<management-FQDN> As long as both firewalls present the same FQDN and use the same service account, Kerberos authentication will work on either unit after failover. Supported configuration Choose a single management FQDN Example: fw-admin.company.com This FQDN must always resolve to the currently active firewall’s management IP. Use one Active Directory service account Example: svc_pan_fw_kerberos This account will be used by both firewalls. Create the SPN (run once in Active Directory) Run the following command from a domain controller or a system with RSAT installed: setspn -A HTTP/fw-admin.company.com svc_pan_fw_kerberos Verify the SPN: setspn -L svc_pan_fw_kerberos Configure both firewalls identically On both HA peers: Use the same Kerberos authentication profile Use the same AD server profile Use the same service account (svc_pan_fw_kerberos) Access the admin UI using the same FQDN (fw-admin.company.com) Access method Administrators must always access the firewall using the shared FQDN, not the individual management IP or hostname of each unit. Important notes Do NOT create separate SPNs per firewall. Do NOT bind the SPN to an IP address. Do NOT use different hostnames for each HA peer. The SPN must be associated with only one AD account. Result With this configuration: Kerberos SSO works on the active firewall After HA failover, Kerberos continues to work without any changes No second SPN is required or supported If Kerberos works on one device today, this means the SPN and service account are already correct. The remaining requirement is to ensure both firewalls use the same configuration and are accessed through the same management FQDN. ... View more

You mentioned “ports link up sequentially, starting from port 1” — there is no documentation that PAN-OS enforces a specific sequential order (Port1 → Port2 → …). Actual behavior: In Shutdown, all passive data interfaces are administratively down and only brought up when active; link up happens as normal OS initialization when the device takes over. knowledgebase.paloaltonetworks.com In Auto, physical interfaces stay up on passive and so sequence is not a factor for failover. knowledgebase.paloaltonetworks.com   “PAN-OS does not document a strict port ordering sequence. In shutdown mode the interfaces are down, so their subsequent ‘up’ event happens during transition; in auto mode they are already up, so no sequence dependency.” Any delay seen during a transition is due to the interface link negotiation (PHY coming up) rather than an explicit documented difference in SFP diagnostics between modes.” Switchover speeds are influenced by whether links are already up (Auto) versus needing to be brought up (Shutdown). There is no separate switchover timer inherent to Auto mode beyond this behavior. Palo Alto Networks recommends Shutdown as the default, especially if the firewall interfaces reside in Layer-2 networks. Auto is recommended only when interfaces do not participate in Layer-2 forwarding to avoid unexpected behavior s it correct that in Shutdown mode delays are OS specification and only way to speed up is Auto mode? Accurate answer: Yes — shutdown behavior keeps passive interfaces down, requiring them to come up only when active. That adds link negotiation delay that cannot be avoided in Shutdown mode. Auto mode eliminates the need for PHY link up during failover by keeping interfaces up. knowledgebase.paloaltonetworks.com Is there loop risk in Auto mode?   Yes — because in Auto mode, passive interfaces are reported as up and neighbors (switches) may send traffic or cause MAC/ARP learning issues if not carefully designed. That’s why documentation explicitly warns not to select Auto if you have Layer-2 interfaces configured.   ... View more

f you have no administrative access at all and no other reachable management method (Panorama, alternate admin account, etc.): You cannot unlock the admin from running config. The typical recovery is to boot the firewall into Maintenance Mode and either: Restore a saved configuration with a known admin, or Default the device and re-apply the config. This is a documented recovery method for when admin access is completely lost. ... View more

The default GP Portal Page can be disabled, so not allow users to try and log onto the web portal of the Global Protect. IThat would eliminate this issue/concern.  ... View more

Why the “backup” tunnels can show RED/DOWN while the primary is working On Palo Alto Networks firewalls, the IPSec tunnel interface status can be driven by tunnel monitoring, not just by whether IKE/IPSec SAs exist. Red/DOWN can mean: tunnel monitor is enabled and the monitoring IP is unreachable, so PAN-OS brings the tunnel interface down (especially when the monitor profile action is Fail Over).  In a “primary/backup” design, if the routing prefers Tunnel.1, then the firewall may have no valid working path over Tunnel.2/3/4 to reach the monitor destination(s) you configured for those tunnels—so their monitors fail and they go red. This is a common misconfiguration pattern: the monitor destination is reachable via the primary tunnel, but not reachable via each backup tunnel specifically. Palo Alto can absolutely have multiple tunnels UP at the same time, but tunnel monitoring can intentionally force a tunnel interface DOWN if its monitor destination is not reachable (by design, to remove routes and trigger failover). What to validate (most common causes) Monitor destination per tunnel Each tunnel should monitor an IP that is reachable only via that tunnel (typical: the remote tunnel interface IP when using route-based VPN). If the monitored IP is “behind” the far side, make sure it’s actually reachable through that specific tunnel during steady state. Ensure the monitor traffic is forced over the intended tunnel The monitor probe follows forwarding; if the “best” route to the monitor destination points at Tunnel.1, then Tunnel.2’s monitor will fail. Fix by using a monitor destination that is topologically tied to that tunnel (again: remote tunnel interface IP is the usual approach for route-based). Policy-based VPN / Proxy-IDs If any of these are policy-based, ensure the monitor destination IPs are covered by Proxy-ID/traffic selectors, otherwise the monitor pings may never match the IPsec SA and will fail. (PAN-OS tunnel monitoring guidance calls out proxy-ID considerations in failover designs.)  Useful verification commands (to include in your response) From the firewall CLI, check whether it’s the monitor driving the red status: show vpn flow (PANW KB explicitly references using this to interpret monitor/tunnel status issues).  Also review System logs for tunnel monitor events (look for tunnel-status-down / monitor failures).  “Red/DOWN on the backup tunnels is expected if tunnel monitoring is configured and the monitoring IP for those tunnels is not reachable via each tunnel. In PAN-OS, tunnel monitoring can intentionally bring a tunnel interface down (especially with Fail Over action) to withdraw routes and enable failover. We should adjust the monitor destination (typically remote tunnel interface IP) and/or routing/traffic-selectors so each tunnel’s monitor probe is reachable over that specific tunnel.” ... View more

The tool, as I understand, has been pulled from the website.  Even if you find the install script, there are tons of updates/libraries, etc., that have been deprecated and are no longer available.      I think the short story is... it is no longer available at all.......     Happy to have someone clarify, so that I am not the doomsayer.  😛 ... View more

Hello The documentation link you would be looking for is here https://docs.paloaltonetworks.com/prisma-access/administration/prisma-access-advanced-deployments/service-connection-advanced-deployments/service-connection-multi-cloud-redundancy From a diagram perspective... Look at this   ... View more

Good Day   A good configuration within the GP config is to have the SAML authentication occur within the GP embedded page.  I am looking to confirm that this is how the experience is, or does the configuration actually open a chrome/edge/firefox browser page when you log in, (known as the default browswer)     Thanks     ... View more

Good Day   Thanks for your message. As more web-based applications are developed and refined, the useage of SSL forward proxy decryption rules may be needed. For example, the FW can easily recognize facebook-base, however of the 10 to 15 sub/child applications under facebook (facebook-post, facebook-chat, facebook-video, facebook-filesharing, etc), these applications may not be seen, as the traffic is still encapsulated packet.  This would be why certain FB applications would still be allowed. As for facebook-base showing up as reddit-base, certainly does not sound correct for a L7 application signature based firewall. You may want to consider opening a TAC case, so they can review/revise the application signatures as needed.     ... View more

Good Day   Thanks for the message.  Our LiveCommunity is volunteer driven with customers and technical contacts. The best way that I may recommend to seek out your answer may be to work with your local PANW Solution Consultant, who is able to open a FR (feature request) ticket, and submit to Product Management for their review and consideration into future product features.  Thank you for your time and consideration in this matter.  ... View more

Good Day   The screen capture you uploaded shows that a password change was required to be performed, along with a commit. I have seen this on my customer projects.   I am not seeing/understanding a connection between a user account and the inability to access the FW.   Dataplane traffic is different from management plane traffic (and an admin account is management plane) Perhaps we are not understanding the challenge you are experiencing. Please feel free to add additional information as needed, and we would be glad to assist you further.   Thank you for your message!!  ... View more

Good Day   I am not sure which version of the SDWAN solution (PanOS vs Prisma SDWAN) you are using, so I am presuming PANOS SDWAN, else you would have mentioned IONs and SCM configurations.   I did not hear mention of the required Panorama and SDWAN licensing in your query.  I presume the SDWAN licensing has been utilized. Can you just confirm that Panorama is also part of the solution, so push down the configurations from the Panorama to the FWs (both HuB and Branch sites)   If you have 3 uplinks of various speeds, the SDWAN configurations (presuming you are using Panorama with current SDWAN plugin) and FWs with the correct SDWAN licensing, should utilize the expected feature that the best link should be used in communicating from Branch to Hub.  How much Hub-sourced to Branch-destined traffic is occurring.   You may want to speak with your local PANW Domain Consultant (formerly SEs) to further assistance.   ... View more