DNS Filtering

[joshow]

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.

[Patterson]

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-tr...

Regards,

Patterson

[Patterson]

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

[joshow]

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?

[Yurisk]

While I understand your disappointment, your conclusions are not entirely correct:

• DNS Filtering is not related to Web Filtering in any way.
• DNS Filtering kicks in first, when a client sends DNS query that FGT sees. One of the benefits of this is saving FGT resources - attempt to access bad website is blocked on the DNS resolving level, even before any HTTP request is sent, and before the Web Filtering kicks in.
• As this is a DNS Filtering - there is no "Redirect" to FQDN/URL as in Web Filtering possible, by DNS protocol,  just replacing bad IP for the Fortiguard IP of the block page on Fortinet servers, so FortiGuard Block page doesn't even see the blocked domain page URL. And true - your browser will show a certificate error, but it is a browser issue, not Fortinet one.  
• Aforementioned Umbrella and others work, just as you said, by installing client side software on each PC, while we talk about a clientless deployment here. May be look into Forticlient + EMS set up, if it can handle what you ask.

[joshow]

You state  "there is no "Redirect to FQDN/URL", but clearly there is. See attached screenshots...




Also, you said that Cisco Umbrella and others work by installing client side software. That is simply not true. I have deployed Cisco Umbrella for two large organizations. There is no client-side software that needs to be installed. In order to avoid the certificate errors, we do have to install a root certificate on the clients though.

[Yurisk]

I meant URL/FQDN redirection as done in Web Filtering so that the remote server gets HTTP GET request where in its headers the original destination is recorded, unlike in DNS FIltering "Redirect" the screenshot of which you brought which "redirects" by replacing IP address in the DNS reply. 

Cisco Umbrella without client - do you mean by any chance using the free OpenDNS-style where only queries are sent to the Cisco ? Then yes, you don't need to install client. But for any of their (Cisco Umbrella) Enterprise offers you do have to install client https://docs.umbrella.com/deployment-umbrella/docs/1-introduction-1 to get the full functionality including custom block messages. I haven't (but did install) seen with ENT clients Umbrella w/o client. 

Cheers.

[sw2090]

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.

[pminarik · Accepted solution]

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.

[joshow]

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)