When setting up SAML IDP on Palo Alto firewall (version 10.0.6) we are importing the XML file provided by our SAML vendor.
However, when importing it we get the following error message:
Upload SAML IDP Failed
Failed to parse IDP Metadata.
The problem is that the “Profile Name” field is limited to 31 characters, but it isn’t validated by the firewall. From the validation when making a new SAML Identity Provider, only alphanumeric characters, underscore ‘_’, hyphen ‘-‘, dot ‘.’ or spaces are permitted.
If you decrease the length of the name, it will import the metadata correctly.
I deployed a Palo Alto VM firewall into Azure recently. Every time I deployed it from the Azure template from the Marketplace or using bootstrap (which still uses the Azure template to get started) the firewall would take about 20-30 minutes and then wind up in maintenance mode without a usable IP address, and no management GUI.
Errors on the serial console were “Entry Reason: System Startup error.” and the Maintenance Entry Reason was “System start failed multiple times. Caused by service: mgmtsrvr”. I deployed the latest version of Palo Alto firewall (version 9.1.3 as of this writing).
Eventually I was able to solve the problem by trying a different password. Even though the template has the following requirements for passwords:
Our original auto generated password that broke the firewall was “wQCoPb7E7T9c5844FbbA@r5iVFQu8V2S” (no quotes). I don’t know if the @ (asterisk) symbol broke the firewall or there was a length issue, but after we changed the password the firewall deployed quickly and easily into Azure. So if you are immediately kicked into maintenance mode with your Palo Alto firewall, try a different password.
Recently we started to get reports of untrusted certificates for AnyConnect and when accessing the ASDM web page. When you browse to the web site it was presenting the default “ASA Temporary Self Signed Certificate” rather than our public SSL certificate.
After opening a case with Cisco TAC about this they pointed us to the release notes issue in ASA 9.4(x):
Elliptic curve cryptography for SSL/TLS—When an elliptic curve-capable SSL VPN client connects to the ASA, the elliptic curve cipher suite will be negotiated, and the ASA will present the SSL VPN client with an elliptic curve certificate, even when the corresponding interface has been configured with an RSA-based trustpoint. To avoid having the ASA present a self-signed SSL certificate, the administrator needs to remove the corresponding cipher suites using the ssl cipher command. For example, for an interface configured with an RSA trustpoint, the administrator can execute the following command so that only RSA based ciphers are negotiated:
ssl cipher tlsv1.2 custom
As soon as I added the command into our ASA it started working again. It sounds like this should be a default entry going forward for all ASA firewalls.
Want to learn more about elliptic curve cryptography or look at this for a primer.