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.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
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"
Regards,
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
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?
Created on 07-17-2023 01:14 AM Edited on 07-17-2023 01:15 AM
While I understand your disappointment, your conclusions are not entirely correct:
Created on 07-17-2023 07:39 AM Edited on 07-17-2023 10:36 AM
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.
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.
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.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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.
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)
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1645 | |
1070 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.