Custom URL won't load images

[mcw015]

I followed the instructions int the Custom-Block_Pages-TN-RevB.pdf, but for whatever reason, the images display as broken links.  When I go directly to the URL for the images, they display just fine.  Any thoughts would be appreciated.

[mikand]

You mean that you want to block a specific url and when you do so the images displays as broken images instead of showing the blocked text?

[mcw015]

No, I am not using the factory default page.  I loaded a custom web page that is supposed to display when a user attempts to visit URL x.x.x.x.  The text of my custom page loads fine but the images that are part of the page display as broken.  When I go straight to the URL of the images the display just fine, but for whatever reason, the href in the custom web page is not being allowed to display those images.  Do I need to add a rule to the firewall to allow web-browsing to allow the palo alto to pull the images?  Or should the page simply grab the images as is?

[ggoudr]

I think that the problem is with your HTML code, it is not palo alto networks related... You should not use the "href  tag for the images to be displayed in the page but the "img src" tag. Try to load the HTML page locally on your PC and see if the image displays correctly there.

[mcw015]

That was my mistake... in the above reply I said "href" but I actually meant "img src".  Here's the full story on what we are trying to do.  I'm at a University and we want to use the PA as our Captive Portal for our guest wireless network.  We cannot use the Captive Portal of the PA because we are not going to be creating hundreds of guest accounts on daily basis, that would be a management nightmare for us.  So to get around this, we are using a URL filtering profile that throws up a custom page with our AUP and an "I Agree" button. 

The images load when I view the page from the Trusted Zone, but they don't load when viewed from Untrusted Zone.  I made a rule to allow any-any-web browsing to the server hosting the images and placed that above the rule that dumps guests into our "captive portal" rule but that did nothing to alleviate the broken images. 

I've attached the html.

[ggoudr · Accepted solution]

I have reviewed your HTML code and carefully read your comments. As I can understand, the captive portal feature of PA is not used at all.

What you are using is a custom "continue and override" page of URL Filtering in combination with a url-filtering profile that has in all categories the "continue" action (or the categories you want to allow).

I have to note the following:

1. The Wireless Guest should be allowed to view the images from the untrusted zone without having to pass through the URL filtering profile, so a rule that allows the Wifi Guest to access the ip of the yamaha server hosting the images (source zone untrust source address will be the subnet of the Wifi Guests, destination zone should be the trusted zone and destination IP of the yamaha server. Also the Wifi Guest must be able to DNS resolve the yamaha host to an IP that must be accessible by him.

I have opened myself the test page attached and indeed the images are shown as broken, because you haven't allowed for me to access the yamaha server from the internet and maybe this or similar is the case of the Wifi clients. Maybe you need to be placed in the Wifi subnet and do the tests from there and modify the firewall rules appropriately in order to be able to view the images on the "continue" page.

Regards,

George

[mikand]

Also since this is a continue-page you can put your images as base64-encoded css stuff. The upside is that everything the client need to properly display your continue-page incl logotypes etc is within the html-code. The downside is that there is a size limit on how large the html code can be thats being stored as a continue (or other type of block) page in PA.

Edit: Here is the doc I was thinking of describing how to setup base64 images through css-style sheet:

[mcw015]

I originally had the permit portion of the rule set to our guest wifi network address range.  This resulted in broken image links.  When we viewed the source of the broken images, each image was being "captive portaled".  We changed the permit rule to our Guest ZONE and poof, everything worked beautifully. 

So the lesson learned, though we aren't entirely sure why, is that for this solution you must permit a zone not an address range. 

Thanks for your help!  We greatly appreciate it.

[mikand]

Im not sure I fully understand what you mean...

Could you bring two examples (or screenshots) on before and after regarding this particular security rule?

[mcw015]

CAVEAT:  Below I use the phrase "Captive Portal" because that is the function we are using this policy for.  In actuality, we are using a URL Filtering policy to match any URL *  ,  *.*  ,  *.*.*  ,  *.*.*.* and loading a Continue and Override Page.  We are NOT using Palo Alto's Captive Portal feature.

The before.jpg image shows how the rule was configured when we were seeing broken image links on our custom page.  When we looked at the URL for the broken images, we noticed that each image was being filtered through the Guest_Captive_Portal rule instead of the Guest_Captive_Portal_JPEGs rule.  So, with our Guest_Captive_Portal_JPEGs rule configured with Source Zone = any and Source Address = Guest WiFi network range, the images weren't loading properly.

The after.jpg image shows how the Guest_Captive_Portal_JPEGs rule is currently configured and working properly.  When we set the Source Zone = Guest-Trust and Source Address = any, the images load without issue. 

Again, we aren't sure why this change made a difference.  If someone can explain to us why that is, we'd greatly appreciate it.  Either way, it is working as desired with the changes identified above.

[ggoudr]

Maybe because the Network 10.101.255.0/24 is not behind the zone Guest-Trust zone.

You should verify in the logs that from the Guest-Trust zone you always have this kind of network and not something else.

So for the second Screenshot I would be more specific and put both the Guest-Trust zone and the Network behind it in the source fields to be more specific.