Admin GUI Login Fails on WAN Interface - Slow Load & "Single Sign-On" Error on PA-410

[bvantala]

Hello Community,

I'm hoping to get some expert advice on an issue I'm facing with a single PA-410 firewall. I've done some initial troubleshooting, but would appreciate a second opinion on the cause and the best path forward.

The Problem

When I enable management access on our public WAN interface (ethernet 1/1), I cannot log in to the Admin Web GUI. The symptoms are very specific:

1. The browser takes a very long time to load the login page.

2. When the page finally loads, it incorrectly displays a "Use Single sign-on" prompt.

3. We do not use SAML SSO or GlobalProtect on this firewall.

Critically, SSH access to the same public IP on the same WAN interface works perfectly fine.

Environment and Configuration

• Device: PA-410

• PAN-OS Version: 11.1.6-h3

• Setup: This is one of eight branch firewalls in a hub-spoke SD-WAN architecture, managed by Panorama.

• Goal: Our objective is to have a reliable, temporary remote access method to the Admin GUI for emergency situations, specifically if the SD-WAN tunnel goes down. Access is restricted via an Interface Management Profile and a Security Policy to a single, trusted public IP.
  
  

  Troubleshooting and Key Findings

  Here’s a summary of what I've found so far:

  • What Fails: Admin GUI login via the WAN port (ethernet1/1)'s public IP.

  • What Works:

    • SSH login via the same WAN port public IP.

    • Admin GUI and SSH login via the dedicated out-of-band management port.

    • Admin GUI and SSH login via an internal LAN interface (a VLAN on ae1.125).

    • The exact same configuration works correctly on the other seven firewalls in our fleet (all running the same PAN-OS version). This strongly suggests a local configuration issue on this specific device, not a bug.

  The most significant finding is related to the firewall's own traffic routing:

  • Service Route Configuration: On the problematic firewall, all services under Device > Setup > Services are configured to source their traffic from the management port. Our DNS servers are internal and only accessible over the SD-WAN tunnel (i.e., via a dataplane interface).
    My theory is that when a GUI login is initiated from the WAN, the firewall's web server attempts a DNS lookup or an authentication check. Because of the service route configuration, this request is forced out of the management port, which has no valid path to our internal DNS servers or the internet. The request eventually times out, causing the web server to fail and render the malformed login page.
    
    
    Questions for the Community

    Given the context, especially the fact that we are in the middle of a critical Panorama migration, I have a few questions:

    1. Is my diagnosis correct? Does the service route configuration seem like the definitive root cause for the web server timeout?

    2. What is the best practice for configuring Service Routes in a branch-office scenario where emergency access over the WAN is required, but primary services (like DNS) are centralized?

    3. What is the recommended solution or workaround? Considering we want to avoid an immediate OS upgrade, what is the safest way to adjust the Service Route configuration to resolve this? For example, should I only change the route for DNS and Authentication, and what should I set the source interface to?

    4. Are there any further troubleshooting steps I should perform? Are there specific logs or CLI commands that could definitively prove the timeout before I make a configuration change? I have packet captures showing the TCP/TLS handshake completes, followed by a stall, which seems to support the timeout theory.