URL Filtering - Override

I have been unable to get the Continue/Override pages working properly on Palo Alto Networks when set to transparent mode under Device→Setup→Content-ID→URL Admin Override. I have also been unable to get it working with loopback interfaces. I suspect the latter issue should be fixable as it implies that the administrator would be limited to response pages on one link only (and that seems crazy).

Under Device→Setup→Content-ID→URL Admin Override, the is a field called “Address” where you can put either the IP address OR FQND of the interface being used on the firewall for response pages. What you put affects the restrictions on certificate creation that are detailed below.

Here are some notes I made on getting the Continue/Override functionality to work properly for Response Page redirects.

• For Firefox 58, I found that if I created a root CA on the firewall and used it as the response page, Firefox threw an error even after I imported it as a trusted CA. The solution was to generate the CA root on the firewall and use that to create a trusted certificate for response pages.
• The response page certificate does not have to be a CA or Subordinate-CA certificate.
• While the response page certificate does not need to be a CA or Subordinate-CA certificate, you do require a CA or Subordinate-CA certificate present on the Palo that is marked as 'Forward Trust Certificate' if you are going to intercept SSL pages correctly. You don't need decryption rules in place, just the Forward Trust Certificate (which is a Trusted Root Authority by all the endpoints using the Palo firewall. Don't forget that Firefox uses its own certificate store).
• You will have to run the following on the Palo firewall CLI (this will automatically sync to a HA partner if there is one so you only have to run this command on one firewall in a pair).set deviceconfig setting ssl-decrypt url-proxy yes
• The firewall will not let us add a hostname in the “Certificate Attributes” section that has a port number attached. However, the Common Name field will accept a port number after the IP (e.g. 1.1.1.1:443)
• Even when the firewall is configured correctly, you will find that several sites will still not be intercepted correctly (e.g. google.com, facebook.com, twitter.com, etc). Firefox (58) will helpfully figure out what is happening and prompt you with a “Open Network Portal page” button that will take you to the response page (thinking it is a guest wifi captive portal page). Google Chrome isn't so helpful and will just display an error. This is due to Google preloading HSTS certificate information into the Chrome executable. Internet Explorer seems similar to Chrome.
• When using rsp.example.local as the address in Device→Setup→Content-ID→URL Admin Override, nothing worked when using on IP information.

To enable Firefox (v49+) to use Windows Certificate Store, run the following steps

1. Type about:config in Firefox's address bar (click through any warnings).
2. Right click and create a new boolean value. Enter (as the name) security.enterprise_roots.enabled.
3. Set the value to true.

If found that Firefox (58), Chrome (64) and Internet Explorer (11) all behaved differently to certificates that I created. The table below shows what happens when using combinations of the “Common Name” field and the “hostname” and “IP” fields of the “Certificate Attributes”. I have split the results into two. The first are when I used and IP as an address in Device→Setup→Content-ID→URL Admin Override→Address field. The second is when I used a FQDN in the Device→Setup→Content-ID→URL Admin Override→Address field.

In summary:

• If you use an IP address in Device→Setup→Content-ID→URL Admin Override→Address field, then you need the IP in the IP field and the IP either the hostname field or the Common Name field or both.
• If you use a FQDN in Device→Setup→Content-ID→URL Admin Override→Address field, then you need the FQDN in the hostname field. The Common Name didn't actually seem important.

In the example below, I either set the Address field to 10.1.1.1 or to rsp.example.com. When you see bad.example.com, that is a test to see how the browser reacts to a different FQDN being used.