Evaluation License - Coming from Palo Alto - Issues with URL Filtering / Application Detection

Forum|Forum|1 year ago
December 30, 2024
8 replies
4080 views

Hi Everyone,

I'm having 10 years of experience with Palo Alto's. We make heavy use of their URL filtering and Application Detection.

In our environment it's not possible to decrypt any traffic, yet the Palo could block all URL's (based on SNI, certificate names etc) but here with the Fortigate Eval License it even refuses to block any webpage using the URL filtering - I've tried "youtube.com", whatsapp.com, facebook.com and none of these work and I'm refusing to believe that this isn't possible with a Forti without decryption.

What I've done:

1. Security Profiles -> Web Filter -> Create New -> Checked URL Filter (Static URL Filter) and I've choosen Wildcard, Block, Enable for *facebook.com* / *whatsapp.com* and "*youtube.com*"
2. I've made sure the Filter is set in "Flow Mode" and hit OK.
3. Created a "Firewall Policy" under "Policy & Objects" that includes this Filter:
Accept, All, All, All, Flow-Based, Web-Filter checked and choosen, SSL-Inspection left on "no-inspection" and asked it to log all sessions.
4. Taking a test-client, and trying to access the pages in question: All of them are accessible. (Sometimes facebook is blocked, even though in the traffic log its shown as "facebook.de" - which shouldnt be blocked in this example).
5. I've checked the traffic is hitting the correct policy (in eval mode you can only have 3 policies, so its not that hard)

6. I've checked the forward logs and I've seen IP's that resolved to whatsapp and others but were allowed ("UTM Allow" or "Accept").

I absolutely need this to work reliable on any webpage - without decryption. Am I missing something obvious?
On the Palo we use this a lot - for instance to create a pop up captive portal, but thats another topic I have yet to figure out here with the Fortigate.
I've done the same testing with using application filters and then using the applications and they too still worked. I did a cross-check against a palo with same configuration and it blocked it.

Thanks for helping out!

Fortigate-VM

Best answer by dingjerry_FTNT

You are right.

dfish85

New Member

Hello,

On the firewall policy you will want to select "certificate-inspection" for the ssl inspection section.

belnea1Author

Explorer

This is decrypting traffic in the background, which requires a certificate to be installed on the client device which is what I cant do.

dingjerry_FTNT

Staff

Hi @belnea1 ,

"no-inspection" means no inspection, so it will not detect any SNI/CN of the certification for inspection.

"Certificate Inspection" will not decrypt/encrypt the traffic.

However, for blocked URLs, we will show the Block Page Replacement Message in HTTPS protocol to the clients and FGT will have to re-sign the response using the self-signed certificate.

This might be an issue for you.

belnea1Author

Explorer

Thank you for your help here but unfortunately what you suggest is not possible for our environment as we are dealing with an airport like situation here - we have thousands of end user devices we do not control.

What other options do we have with the Fortigate?
Maybe we can we simply disable the response page in order to avoid that certificate error as long as the blocking works?

One example use case where I would need that block page though would be the aforementioned captive portal popup. I'm not there yet on the Forti but on the Palo we are using response pages to redirect unauthenticated users (depending on what kind of subnet they come from) to a locally hosted captive portal page of our choice. Since the block page is configurable, I hope would this will be possible on the Fortigate as well? The captive check traffic from the devices is always HTTP, so interception (& redirect) here should not need any certificate inspection / MIMT.