How the Web Filter Works

I’m assuming you’re using webfilter profiles with policies. 
To allow a specif URL with HTTPS from a particular IP, you have to have a specific policy matching the source IP with the action:allow in the policy and place it above any other deny policies. Then in the policy, you want to have a webfilter profile that has a URL filter configured with the full URL:
dl.k8s.io/release/v1.36.1/bin/windows/amd64/kubectl.exe
and “Exempt” if you want to skip any other NGFW action against it.
Then, of course you need to have some deny policies below the allow policy to block anything else you want to block from the source IP, or all others.
You need to have at least “certificate-inspection” (prebuilt/unchangeable) inspection profile to filter HTTPS traffic. If you want to modify some behaviors with the certificate-inspection, you need to clone it first, then modify it, and then use it in the policy.

Toshi

“Simple” should be fine because you put the exact full URL into the URL filter entry. There is no wildcard ‘*’ or regex involved.

Deep inspection is when you want the FGT to look into the content of traffic with IPS, Antivirus, Application control, and so on, because the packets are encrypted by TLS. And to implement that, you need to have a CA certificate and endpoint certificates singed by the CA and intall them to individual devices and the FGT. For URL filtering, it’s not necessary.

Toshi

Monitor doesn’t block the other pages at the same host. You have to Block the rest like below. As I said before, “certificate-inspection” should be enough even HTTPS traffic. You can easily test it yourself using the same webfilter profile with a policy applied to your test device IP. That’s the ultimate way to confirm the behaviors of webfiltering. And, let us know if it behaves differently.

Toshi