Visitor III

Solved

DNS Filtering

Forum|Forum|3 years ago
July 14, 2023
13 replies
29104 views

I have a Fortigate 40F. I have been trying for weeks to get DNS Filtering working. The basic setup is simple. When a user goes to a restricted site they do get redirected but the Block Page will not show up as there is a certificate error. (This is understandable since the Fortigate cert does not have the same name as the page the person is trying to go to).

For Web Filtering the solution was to download, install and trust the default Fortigate cert. This works for Web Filtering but it does not work for DNS Filtering.

I have Googled endlessly with no solution. I have a support case open with Fortinet. So far, they have not been able to provide a solution.

If anyone can help with this, it would be much appreciated.

FortiGate

Best answer by pminarik

DNS filter by default simply points to an IP of what should be a webserver capable of displaying a generic "this website is blocked" error message.

The default IP (FortiGuard's own) is currently 208.91.112.55 and that site has a generic self-signed certificate (it will never match what the client is requesting, so there's no point in using a cert valid for anything). Note that you can replace this with your own internal server if you so desire.

update: The suggested solution below will not work.

~~Here's what you can do if you would like to remove the certificate warning for end-users.~~

~~1, Create a separate policy that allows specifically just the destination 208.91.112.55 and HTTP/HTTPS access.~~

2, Use a custom deep-inspection profile in this policy. This profile needs to get tweaked a bit: Disable SNI check, set "untrusted" to "ignore" (if you don't, you will end up with a certificate warning again). You still need this profile to use a CA certificate that is trusted by your client devices.

~~3, Optionally do not use webfilter in this policy, so as not to generate double the UTM logs (DNS + webfilter for the same access attempt)~~

~~This should eventually get you to a "webpage blocked" page with no certificate warning.~~

There's an obvious caveat - if you can't handle webfiltering neatly already (custom CA certificate imported to/trusted by endpoint devices), then you will run into the very same issue with DNS filtering and the above solution as well.

Patterson

Staff

Hi @joshow ,

I understand that your looking for a replacement message if the DNS filter is blocking the access based on your configuration.

Since this is a DNS query initiated, FGT can't responds back with http responds. Instead we have the option to re-direct blocked request to a different IP. Here by default FGT use "208.91.112.55" (Fortiguard default), you can specify custom IP of your own also.

Now your browser will initiate a traffic towards this IP will get a responds as "Web page blocked"

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Web-Page-Blocked-error-when-users-try/ta-p/227243

Regards,

Patterson

Staff

Hi @joshow ,

I missed the part of cert error mentioned.

As checked the CN/SNI in SSL certificate we not get matched even with deep-inspection.

Suggesting to use Web-filter along with DNS-filter.

Regards,

Patterson

joshowAuthor

Visitor III

I have been able to use web filtering successfully, but then why use both. Web filtering cuts in first and DNS filtering is therefore not really doing anything.

Other DNS filtering services work fine. For example - OpenDNS/Cisco Umbrella. They encounter the same issue but it is resolved by downloading and installing a cert that they supply. Why cant Fortinet find a way to make this work in the same way?

sw2090

SuperUser

DNS filter itself doesn't show any blocking page it will respond the DNS query with a "NXDOMAIN" instead.

If there appears to be a blocking page it is from yet annother filter or DNS filter is not blocking the page and then there is DPI ineffect or something similar.

pminarikAnswer

Staff

DNS filter by default simply points to an IP of what should be a webserver capable of displaying a generic "this website is blocked" error message.

The default IP (FortiGuard's own) is currently 208.91.112.55 and that site has a generic self-signed certificate (it will never match what the client is requesting, so there's no point in using a cert valid for anything). Note that you can replace this with your own internal server if you so desire.

update: The suggested solution below will not work.

~~Here's what you can do if you would like to remove the certificate warning for end-users.~~

~~1, Create a separate policy that allows specifically just the destination 208.91.112.55 and HTTP/HTTPS access.~~

2, Use a custom deep-inspection profile in this policy. This profile needs to get tweaked a bit: Disable SNI check, set "untrusted" to "ignore" (if you don't, you will end up with a certificate warning again). You still need this profile to use a CA certificate that is trusted by your client devices.

~~3, Optionally do not use webfilter in this policy, so as not to generate double the UTM logs (DNS + webfilter for the same access attempt)~~

~~This should eventually get you to a "webpage blocked" page with no certificate warning.~~

There's an obvious caveat - if you can't handle webfiltering neatly already (custom CA certificate imported to/trusted by endpoint devices), then you will run into the very same issue with DNS filtering and the above solution as well.

joshowAuthor

Visitor III

I gave your solution a try. So far it is not working, but maybe I missed something. I am attaching screenshots of the new Firewall Policy I created along with the custom deep-inspection policy. Maybe your eye will catch something I did wrong. (The Destination > Fortinet Block Portal is the IP address of the Block Portal (208.91.112.55)

Screenshot 2023-07-20 at 7.05.15 PM.png Screenshot 2023-07-20 at 7.16.52 PM.png

pminarik

Staff

The SSL inspection profile doesn't actually do anything in the absence of any other UTM profile. Try adding some simple/dummy profile (e.g. IPS), and it should start working. The rest looks fine at a glance.

(keeping in mind that the original session/caching may take a sec to clear out after the change is saved)