DNS Filtering

joshow · ‎07-14-2023

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.

pminarik · ‎07-17-2023

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.

[ corrections always welcome ]

View solution in original post

pminarik · ‎07-21-2023

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)

[ corrections always welcome ]

joshow · ‎07-22-2023

Thanks. Tried adding IPS profile. I'm still getting a certificate error. Maybe I am still missing something. Have you actually tested this solution in a lab or anything?

I am about to give up on this. I had opened a case with Fortinet. They had no solution. They told me the certificate error is "expected behaviour". I told them that is unacceptable. The documentation clearly states that when a web page is blocked because it is in a filtered category, the user should be redirected to a block site. What is the point of that, if the user gets a cert error instead of the block page message explaining to them what happens.

I guess I will just used Web Filtering, but it bothers me that I pay for this service as part of my license and it does not work properly.

pminarik · ‎07-24-2023

Turns out this indeed will not help. I failed to account for one thing: If you disable the validation checks in the inspection profile, the original certificate will get re-signed with the "trusted" DPI CA (thus having the potential to be trusted by the client), but there's no modification of the values in the rewritten certificate (normal, expected), whicn means it keeps the original certificate's SAN mismatch with the FQDN being accessed. So this will actually never work. I will update the original reply.

> I guess I will just used Web Filtering, but it bothers me that I pay for this service as part of my license and it does not work properly.

Here's the thing: DNS filtering, by virtue of the filtering happening at the "layer" of the DNS protocol, can't do anything about certificates. To give you some credit, this could be advertised better in the documentation.

If your goal is to block website traffic, a webfilter is the more appropriate UTM profile anyway. To be frank, DNS is more suited for non-HTTP/S traffic (block page irrelevant), or in situations where you can't distribute the DPI CA certificate to endpoints (no way to avoid certificate warnings).

If you are in a situation where you have enough control over the endpoints to ensure that they trust your DPI CA, go with a webfilter profile.s

[ corrections always welcome ]